Training Module
OpenTelemetry: Vendor-neutrale Instrumentierung für Traces, Metrics & Logs
Ihr kennt Prometheus, Grafana oder Jaeger bereits als Backend, aber die
Instrumentierungsebene davor blieb bisher Konzept statt eigener Code.
In diesem 180-Minuten-Einstiegsmodul holt ihr das nach: OpenTelemetry
als vendor-neutraler Standard unter CNCF-Führung für die drei Signale Traces, Metrics und Logs, klar
abgegrenzt vom Vendor-Lock-in eines einzelnen Jaeger-Clients oder
Prometheus-Clients. Ihr instrumentiert eine Node.js-App zuerst
automatisch über
@opentelemetry/auto-instrumentations-node und exportiert
Traces per OTLP/gRPC an einen lokalen Collector-Container.
Danach baut ihr eure eigene Collector-Pipeline aus
Receiver, Processor und Exporter in einer eigenen
collector-config.yaml: Traces fließen zu Jaeger, Metrics
aus derselben Instrumentierung zu Prometheus, in einem
Vier-Dienste-Compose-Stack aus App, Collector, Jaeger und Prometheus.
Im dritten Hands-on-Block ergänzt ihr manuelle
Instrumentierung: ein eigener Custom-Span, Context Propagation
über zwei Microservices hinweg und die Trace-ID im strukturierten Log,
damit ein Log-Eintrag auf den zugehörigen Trace zurückführbar bleibt.
Zum Abschluss ordnet ein Ausblick ohne eigenes Hands-on Sampling-Strategien
und Collector-Deployment-Pattern in Kubernetes konzeptionell ein.
Format
180 Minuten (3 Stunden), live (remote oder vor Ort), Input, Live-Coding und Hands-on, rein lokal über Docker Compose, Hands-on-Anteil rund 60 Prozent der Zeit
Teilnehmende
Entwickler:innen und Ops mit Docker-Compose-Erfahrung, die Prometheus/Grafana oder Jaeger bereits als Backend kennen, aber die Instrumentierungsebene bisher nur konzeptionell
Voraussetzungen
Docker-Compose-Grundkenntnisse. Keine Kubernetes-Pflicht. Prometheus/Grafana-Praxis aus dem Modul “Docker Betrieb” oder Jaeger-Praxis aus dem Modul “Kubernetes Service Mesh: Distributed Tracing mit Jaeger” hilfreich, keine Pflicht.
Warum dieses Training für deine Organisation wirkt
Ein Standard statt drei Clients
Statt einen Jaeger-Client, einen Prometheus-Client und eine eigene Log-Bibliothek getrennt zu pflegen, instrumentiert ihr einmal gegen das CNCF-Graduated-Projekt OpenTelemetry und wechselt das Backend, ohne den Instrumentierungscode anzufassen.
Von Auto-Instrumentierung zu eigenem Span
Auto-Instrumentierung liefert die ersten Traces ohne Codeänderung; der eigene Custom-Span und Context Propagation über zwei Microservices zeigen, wo automatische Instrumentierung endet und manuelle beginnt.
Eine Pipeline, zwei Backends
Eine selbst konfigurierte Collector-Pipeline aus Receiver, Processor und Exporter schickt Traces an Jaeger und Metrics an Prometheus aus derselben Instrumentierung, statt zwei getrennte Export-Wege zu pflegen.
Was Teilnehmende mitnehmen
- Die drei OpenTelemetry-Signale Traces, Metrics und Logs benennen und das Vendor-Lock-in-Problem eines einzelnen Jaeger-Clients oder Prometheus-Clients einordnen.
- Die Architektur aus API, SDK und Collector sowie Context Propagation über W3C Trace Context (
traceparent) und Resource-Attribute erklären und Auto- von manueller Instrumentierung abgrenzen. - Eine Node.js-App per
@opentelemetry/auto-instrumentations-nodeautomatisch instrumentieren und Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren. - Eine eigene
collector-config.yamlmit Receiver, Processor und Exporter bauen, die Traces an Jaeger und Metrics an Prometheus aus derselben Instrumentierung ausgibt, in einem Vier-Dienste-Compose-Stack. - Einen eigenen Custom-Span manuell setzen, Context Propagation über zwei Microservices hinweg nachvollziehen und die Trace-ID im strukturierten Log zur Korrelation nutzen.
- Sampling-Strategien (Head-/Tail-based), Collector-Deployment-Pattern in Kubernetes (Sidecar, DaemonSet, Gateway) und Cardinality-Fallstricke konzeptionell einordnen, ohne eigenes Hands-on zu diesen Punkten.
Für wen dieses Modul ideal ist
- • Entwickler:innen und Ops mit Docker-Compose-Erfahrung, die eine Observability-Backend-Entscheidung (Jaeger, Prometheus) bereits kennen
- • Teams, die Instrumentierungscode nicht länger an ein einzelnes Backend binden wollen
- • Wer Kubernetes nicht zwingend braucht: der gesamte Hands-on-Teil läuft lokal über Docker Compose
Rahmendaten
- • Dauer: 180 Minuten (3 Stunden) live (remote oder vor Ort)
- • Format: Input, Live-Coding, drei Hands-on-Blöcke gegen einen lokalen Docker-Compose-Stack, Hands-on-Anteil rund 60 Prozent der Zeit
- • Voraussetzungen: Docker-Compose-Grundkenntnisse, keine Kubernetes-Pflicht; Prometheus/Grafana- oder Jaeger-Praxis hilfreich, keine Pflicht
Modulaufbau & Agenda
Warum OpenTelemetry? Drei Signale & Vendor-Lock-in-Problem (20 min): Traces, Metrics und Logs als die drei Signale, Abgrenzung zu einem fest verdrahteten Jaeger-Client oder Prometheus-Client, OpenTelemetry als CNCF-Graduated-Projekt.
Architektur: API, SDK, Collector & Context Propagation (25 min): Trennung von API und SDK, Rolle des Collectors, W3C Trace Context (
traceparent) und Resource-Attribute, Abgrenzung Auto- vs. manuelle Instrumentierung.Hands-on: Auto-Instrumentierung & OTLP-Export (35 min): eine Node.js-App per
@opentelemetry/auto-instrumentations-nodeautomatisch instrumentieren und Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren.Hands-on: Collector-Pipeline (Receiver, Processor, Exporter) (40 min): eine eigene
collector-config.yamlbauen, die Traces an Jaeger und Metrics an Prometheus aus derselben Instrumentierung ausgibt, im Vier-Dienste-Compose-Stack aus App, Collector, Jaeger und Prometheus.Hands-on: Manuelle Instrumentierung & Log-Korrelation (35 min): einen eigenen Custom-Span setzen, Context Propagation über zwei Microservices nachvollziehen und die Trace-ID in einem strukturierten Log platzieren.
Produktionsbetrieb-Ausblick ohne Hands-on & Q&A (25 min): Sampling-Strategien (Head-/Tail-based), Collector-Deployment-Pattern in Kubernetes (Sidecar, DaemonSet, Gateway, rein konzeptionell), Cardinality-Fallstricke, offene Fragen.
Hands-on Inhalte (Auszug)
Auto-Instrumentierung & OTLP-Export
- Node.js-App per
@opentelemetry/auto-instrumentations-nodeinstrumentieren - Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren
- Erste Traces ohne manuellen Instrumentierungscode nachvollziehen
Collector-Pipeline
- Eigene
collector-config.yamlmit Receiver, Processor und Exporter - Pipeline Traces zu Jaeger und Metrics zu Prometheus aus derselben Instrumentierung
- Vier-Dienste-Compose-Stack: App, Collector, Jaeger, Prometheus
Manuelle Instrumentierung
- Eigenen Custom-Span setzen
- Context Propagation über zwei Microservices nachvollziehen
- Trace-ID im strukturierten Log zur Korrelation nutzen
Produktionsbetrieb-Ausblick (Konzept, kein Hands-on)
- Sampling-Strategien: Head-based vs. Tail-based
- Collector-Deployment-Pattern in Kubernetes: Sidecar, DaemonSet, Gateway
- Cardinality-Fallstricke bei Resource- und Span-Attributen
Abgrenzung dieses Moduls: keine produktive Collector-Skalierung oder Hochverfügbarkeit in Kubernetes, kein eigenes Hands-on zu Tail-based Sampling, keine eigene Übung zu Collector-Deployment-Pattern in Kubernetes und kein vendor-spezifisches Backend-Tuning. Den eigenen Prometheus/Grafana-Stack im Compose-Setup baut das Modul Docker Betrieb auf, Jaeger als Backend samt Sampling-Konfiguration und Storage-Backend-Ausblick das Modul Kubernetes Service Mesh: Distributed Tracing mit Jaeger. Beide Backends setzt dieses Modul als bekannt voraus oder nutzt sie nur als Exportziel der eigenen Collector-Pipeline.
Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum ersten erfolgreichen OTLP-Export, Ergebnis der Log-Korrelations-Übung) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.
Bereit, das Modul zu buchen?
Wir passen die Hands-on-Blöcke auf euren vorhandenen Backend-Stack (Jaeger, Prometheus) an.
Academy Briefing anfragen