OpenTelemetry (kurz OTel) ist ein herstellerneutrales Projekt, das ein einheitliches Datenmodell, Software-Bibliotheken und ein Protokoll für Telemetriedaten bereitstellt. Ziel ist, dass Anwendungen Messdaten in einem Format liefern, das jedes beliebige Backend aufnehmen kann – ohne dass Code beim Anbieterwechsel angepasst werden muss. Das Projekt ist aus der Zusammenführung von OpenTracing und OpenCensus entstanden und im Mai 2026 von der CNCF zum Graduated Project erklärt worden.
Drei Signale, ein Modell
- Traces – der Weg einer Anfrage durch mehrere Dienste, bestehend aus Spans mit Startzeit, Dauer, Status und Attributen. Verteiltes Tracing macht Latenz sichtbar, die sich zwischen Diensten versteckt.
- Metriken – Zähler, Verteilungen und Messwerte, etwa Antwortzeiten als Histogramm.
- Logs – Textmeldungen, die mit Trace- und Span-ID verknüpft werden können.
Die entscheidende Idee ist die Verknüpfung: Ein Logeintrag trägt eine trace_id, ein Span trägt dieselbe ID – dadurch lässt sich vom Fehlerprotokoll direkt zum vollständigen Request-Verlauf springen. Genau das unterscheidet Observability von reinem Monitoring.
Collector und Kontext-Propagation
Zentraler Baustein ist der OpenTelemetry Collector. Er nimmt Daten über das Protokoll OTLP (gRPC oder HTTP) entgegen, kann sie bündeln, filtern, anreichern und an mehrere Ziele weiterleiten. Läuft er als Agent auf jedem Knoten, spricht man von einer DaemonSet-Bereitstellung; als zentrale Instanz sammelt und verteilt er an Backends wie Jaeger, Tempo, Prometheus oder einen kommerziellen Anbieter.
Ebenfalls zentral ist die Kontext-Propagation: Über HTTP-Header wie traceparent (W3C Trace Context) reicht jede Anwendung die Herkunft der Anfrage an die nächste weiter. Nur so entsteht aus einzelnen Spans ein zusammenhängender Trace.
Praxis
Der Nutzen wächst mit der Verteilung. Bei einer Anwendung mit Datenbank und Webserver genügt oft noch ein Log und ein Metrik-Dashboard; bei Microservices mit mehreren Sprüngen pro Anfrage ist Tracing die einzige wirtschaftliche Diagnosehilfe. Der Preis ist Aufwand: SDK-Initialisierung in jeder Sprache, Sampling-Strategie gegen Datenflut und Betrieb des Collectors. Die automatische Instrumentierung ist in vielen Sprachen inzwischen ausgereift, sodass ein großer Teil ohne Codeänderung abgedeckt ist.
Verwandte Grundlagen: Observability, Jaeger, Loki, Monitoring mit Prometheus und Grafana.