Jaeger ist ein quelloffenes Backend für Distributed Tracing — also die Nachverfolgung einer einzelnen Anfrage auf ihrem Weg durch viele Microservices. Entwickelt wurde Jaeger ab 2015 bei Uber, 2017 als Open Source veröffentlicht. Es wurde ein Projekt der Cloud Native Computing Foundation (CNCF) und erreichte 2019 als eines der ersten Projekte den Graduated-Status — damit gehört es zu den etablierten Bausteinen moderner Observability-Stacks.
Warum Distributed Tracing?
In verteilten Systemen durchläuft eine Anfrage typischerweise mehrere Dienste: API-Gateway, Authentifizierung, Datenbank, Zahlungsdienst. Fällt etwas aus oder wird langsam, ist ohne Tracing kaum nachvollziehbar, welcher Schritt wie lange gedauert hat — einzelne Monitoring-Werte je Dienst zeigen das Gesamtbild nicht. Traces rekonstruieren genau diesen Weg.
Grundkonzepte: Traces und Spans
- Trace: Die komplette Ende-zu-Ende-Anfrage. Eine gemeinsame Trace-ID verbindet alle beteiligten Dienste.
- Span: Eine benannte Arbeitseinheit innerhalb des Trace, z.B. „Datenbankabfrage" oder „Authentifizierung prüfen". Ein Span besitzt Startzeit, Dauer, Tags und Logs.
Die Spans eines Trace bilden einen Baum: Jeder Span kann Eltern-Kind-Beziehungen haben („Version 2 ruft Version 1 auf"). Genau diese Struktur zeigt Jaeger in seiner Weboberfläche als Wasserfall-Ansicht oder Flame-Graph — man sieht auf einen Blick, wo die Zeit verloren geht. Zusätzlich erzeugt Jaeger ein Abhängigkeits-Diagramm der Dienste (Service-Dependency-Graph). Als Speicher dienen Cassandra, Elasticsearch oder S3-kompatible Objekt-Stores.
Jaeger und OpenTelemetry
Die Instrumentierung der Anwendungen übernimmt heute meist OpenTelemetry: Dessen APIs und SDKs erzeugen Spans und senden sie per OTLP. Jaeger empfängt diese Telemetriedaten und ist damit primär das Speicher- und Analyse-Backend. Seit Version 1.35 kann es OTLP direkt empfangen; mit Jaeger v2 (November 2024) ist OpenTelemetry vollständig in den Kern eingezogen — Jaeger v2 läuft als OpenTelemetry-Collector-Distribution, die Traces verarbeitet, aggregiert und visualisiert. Damit ist der Stack sauber getrennt: OpenTelemetry liefert die Daten, Jaeger zeigt sie.
Sampling bei hohem Traffic
Bei starkem Aufkommen wird gesampelt: Statt jedes Trace zu speichern, entscheiden Strategien wie probabilistisches Head-Sampling (Zufallsauswahl am Anfang) oder Tail-Sampling (Entscheidung am Ende anhand von Fehlern oder Latenz), welche Traces wirklich abgelegt werden. Das hält Speicher und Kosten im Rahmen, während typische Fehlerbilder trotzdem erfasst bleiben.
In Kubernetes-Umgebungen laufen Jaeger und seine Collector-Komponenten als Container (Kubernetes, Docker); auch ein Service-Mesh wie Istio kann Tracing-Daten direkt an Jaeger liefern. In Grafana lassen sich Jaeger-Daten über eine Datenquelle neben Metriken und Logs anzeigen — Metriken sagen, dass etwas langsam ist (Prometheus), Logs, was passiert ist (Loki), und Traces, wo die Zeit verloren geht.