Verteiltes Tracing im Überblick: Spans, Parent-IDs und die Weitergabe des W3C-Trace-Kontexts

Worum es geht

Ein Trace zeichnet eine Anfrage auf, während sie mehrere Dienste durchläuft. Er ist ein Baum aus Spans. Die OpenTelemetry-Dokumentation listet auf, was ein Span enthält: einen Namen, eine Parent-Span-ID (leer beim Root-Span), Start- und Endzeitstempel, einen Span-Kontext (Trace-ID und Span-ID), Attribute, Events, Links und einen Status. Jeder Span hat zudem eine Art (Client, Server, Internal, Producer oder Consumer), die dem Backend sagt, wie der Baum zusammenzusetzen ist: Der Parent eines Server-Spans ist oft ein entfernter Client-Span.

Der Baum entsteht nur, wenn Kennungen die Prozessgrenzen überschreiten. Die W3C-Trace-Context-Empfehlung definiert dafür den HTTP-Header traceparent: version-trace-id-parent-id-trace-flags, wobei die Trace-ID aus 32 Kleinbuchstaben-Hex-Zeichen (16 Byte) besteht, die Parent-ID aus 16 Hex-Zeichen (der ID des aufrufenden Spans), und das Flags-Byte derzeit ein Bit trägt, sampled. Ein zweiter Header, tracestate, enthält anbieterspezifische Daten. Die Empfehlung nennt zwei Stufen: Ein Tool muss mindestens beide Header weiterleiten, damit Traces nicht unterbrochen werden (Forwarding), oder es kann teilnehmen, indem es einen eigenen Span erzeugt und die Parent-ID umschreibt. Die OpenTelemetry-Seite zur Kontextweitergabe beschreibt denselben Mechanismus: Der Aufrufer übergibt Trace-ID und Span-ID, der Aufgerufene erzeugt einen Kind-Span mit dem Span des Aufrufers als Parent.

Warum es wichtig ist

Logs von zehn Diensten beschreiben zehn getrennte Ereignisse; ein Trace zeigt, welche zu einer Anfrage gehören, in welcher Reihenfolge und wo die Zeit verging. Ohne Weitergabe startet jeder Dienst einen eigenen Root-Span, und das Backend zeigt Fragmente, die sich nicht zusammenfügen lassen.

So wird es angewendet

• Für jede eingehende Anfrage einen Server-Span erzeugen und für jeden ausgehenden Aufruf, jede Nachrichtenveröffentlichung oder Datenbankabfrage einen Client-Span; Instrumentierungsbibliotheken von Frameworks tun dies automatisch.
• Die Weitergabe über alles hinweg sicherstellen, nicht nur über HTTP: traceparent in Nachrichten-Header für Queues und in die Job-Payload für Hintergrundarbeit legen und im Consumer wiederherstellen.
• Die Trace-ID in jede Log-Zeile der Anfrage schreiben, damit sich Logs und Traces zusammenführen lassen.
• Span-Namen mit niedriger Kardinalität halten (GET /users/{id}, nicht die konkrete URL); variable Teile in Attribute legen.
• Dienste, die kein Tracing-SDK ausführen, sollten traceparent und tracestate trotzdem unverändert weiterleiten.

Stolpersteine

An asynchronen Grenzen (Thread-Pools, Timer, gebündelte Writer) geht der Kontext verloren, sofern ihn die Bibliothek oder der Code nicht ausdrücklich mitführt. Das sampled-Flag ist ein Hinweis des Aufrufers; eine pro Dienst getroffene Sampling-Entscheidung erzeugt Traces mit fehlenden Spans. Uhrenabweichungen zwischen Hosts können dazu führen, dass ein Kind-Span scheinbar vor seinem Parent beginnt. Eine öffentliche Kante sollte bewusst entscheiden, ob sie einen von einem beliebigen Client mitgelieferten Trace fortsetzt.