Mitglied werden – KI-Tutor mit vollen Antworten

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-node automatisch instrumentieren und Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren.
  • Eine eigene collector-config.yaml mit 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

  1. 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.

  2. 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.

  3. Hands-on: Auto-Instrumentierung & OTLP-Export (35 min): eine Node.js-App per @opentelemetry/auto-instrumentations-node automatisch instrumentieren und Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren.

  4. Hands-on: Collector-Pipeline (Receiver, Processor, Exporter) (40 min): eine eigene collector-config.yaml bauen, die Traces an Jaeger und Metrics an Prometheus aus derselben Instrumentierung ausgibt, im Vier-Dienste-Compose-Stack aus App, Collector, Jaeger und Prometheus.

  5. 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.

  6. 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-node instrumentieren
  • Traces per OTLP/gRPC an einen lokalen Collector-Container exportieren
  • Erste Traces ohne manuellen Instrumentierungscode nachvollziehen

Collector-Pipeline

  • Eigene collector-config.yaml mit 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