Jaeger

Entwickelt von Uber. Standard für Kubernetes. Du musst deinen Code anpassen (Instrumentation): "Starte Span 'DB-Query'..." -> "Beende Span". Dank OpenTelemetry geht das heute oft automatisch (Auto-Instrumentation), ohne Code zu ändern.

1. Sampling

Wenn du jeden einzelnen Request tracest, explodiert deine Festplatte. (Traces sind riesig). Jaeger macht Sampling. "Speichere nur 0.1% aller Requests." Oder "Adaptive Sampling": "Speichere alle Fehler, aber nur wenige erfolgreiche Requests."

2. Context Propagation

Wie kommt die Trace ID von Service A zu Service B? Über HTTP-Header (uber-trace-id oder traceparent). Wenn du vergessen hast, den Header weiterzuleiten, bricht der Trace ab ("Broken Trace") und du bist blind.

1. B3 Propagation und W3C Trace Context

Das chaotische Problem von HTTP Traces im Web war lange: Jeder Tracer benutzte proprietäre Header Puffer (Jaeger nutzte uber-trace-id, Zipkin nutzte X-B3-TraceId). Traffic von DataDog flog gegen Kubernetes-Jaeger blind. Das tiefe Fundament legte der W3C-Standard (W3C Trace Context), erzwungen via OpenTelemetry: Die Injectors schreiben genannte Hex-Sequenzen universell in das HTTP-Header Feld traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01. Dies packt kryptografisch sauber die TraceID (gesamte Journey) und ParentSpanID (vorheriger API-Call). Der 01-Flag am Ende entscheidet deterministisch über das Sampling-Flag (soll dies von Endospeichern weitergeloggt werden oder weggeworfen?).

2. Tail-Based Sampling (Der Holy Grail of Error Catching)

Die Sampling-Krise traf alle: "Wir haben 10 Millionen Calls. Jaeger speichert 1%. Plötzlich schlägt Call Nr 401345 mit einem fetten 500er Error-Code fehl." Problem: Jaeger hatte zu 99% Wahrscheinlichkeit den Anfang dieses Traces (den Frontend-Span und Header) per "Head-Based Sampling" blind weggeschnitten, noch bevor der Fehler stattfand. Devs waren wieder blind! Enterprise OTel-Collectors installieren Tail-Based Sampling. Sämtliche Hundertausend Traces fliegen erst in einen gewaltigen OTel-Cache (Ring Buffer in RAM). Dort versauern die Traces als "Warte-State" für 30 Sekunden. Der Tracer analysiert den fertigen Baum rückwärts. Wenn ganz unten im Sumpf ein error: true Attribut gesetzt ist, triggert der Dump panisch den Collector und spült den exakten, vollständigen Trace retrospektiv auf Disk. "Gute" Traces werden zu 100% aus dem RAM gedroppt (Ignoriert). Massiver RAM Verbrauch, absolut geniale Root-Cause Rettung.

3. Dapper Paper und DAG-Rekonstruktion in Cassandra

Jaeger stammt historisch als Fork stark vom 2010 erschienenen Google Paper ("Dapper"). Das kritische Kernstück moderner Tracestruktur ist die asynchron-desorientierte Datensammel-Sucht des Systems. Spans 10 bis 40 (aus SQL DB, Auth, Microservices) rasen via UDP/gRPC völlig zeitlich verwürfelt im Sammler-Gateway ein (aus allen Kontinenten). Die Abspeicherung wandert idealerweise auf Apache Cassandra (High-Write Throughput NoSQL). Um den Gantt-Chart Baum zu formen (DAG Directed Acyclic Graph), nutzt die Cassandra Spezifikation in der Partition Key Abfrage strikt die zentrale TraceID. Die Retrieval Engine fischt nachher diese Milliarden Datensätze ab, liest die verstreuten ParentID -> ChildID Links und formt den O(N) Graphen deterministisch im RAM, wobei sie Zeitsync-Clock-Drifts über Hardware-Sensoren glättet (Skew-Compensation), damit im UI die Backend-Antwort nicht in der Zeit vor dem Kunden-Click stattfände (was passiert, wenn Server-Uhren der Hosts asynchron laufen!).