Begriff
Traces (Distributed Tracing)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir vor, du bestellst eine Pizza.
- Du rufst an (App).
- Die Bestellung geht in die Küche (Service A).
- Die Küche bestellt Zutaten beim Lager (Service B).
- Der Fahrer bekommt eine Route (Service C). Wenn die Pizza 2 Stunden zu spät kommt – wo lag der Fehler? Normale Logs sagen nur: "Küche sagt: fertig". Aber sie sagen nicht, welche spezifische Pizza gemeint war. Ein Trace ist wie ein GPS-Tracker für einen einzelnen Request. Er bekommt eine eindeutige Trace ID. Jede Station (Service), die der Request passiert, stempelt die ID ab und sagt: "Ich habe hier 5 Minuten gearbeitet." Am Ende siehst du eine Zeitachse (Gantt-Diagramm) und weißt genau: "Ah, das Lager hat 45 Minuten gebraucht, um den Käse zu finden."
Merksatz: Ein Trace dokumentiert den vollständigen Weg einer einzelnen Anfrage durch ein verteiltes System (Microservices) und visualisiert die Latenzzeiten der beteiligten Komponenten.
Du nutzt Frameworks wie OpenTelemetry (OTel). Jeder Service schickt kleine Datenpakete (Spans) an ein zentrales System wie Jaeger, Tempo oder Honeycomb. Ein Span enthält:
- Name der Operation (z. B.
GET /user). - Start- und Endzeit.
- Tags (z. B.
http.status_code=200). In der UI von Jaeger kannst du nach der Trace ID suchen und siehst den kompletten Baum der Aufrufe.
1. Context Propagation
Das Wichtigste an Tracing ist, dass die Trace ID von Service A zu B "wandert".
Das nennt man Context Propagation.
Meistens geschieht das über HTTP-Header (z. B. traceparent nach W3C-Standard).
Wenn Service A einen API-Call an B macht, injiziert er die ID in den Header. Service B extrahiert sie und startet einen "Child Span". Wenn ein Programmierer vergisst, den Header weiterzureichen, "reißt" der Trace ab – ein häufiger Fehler.
2. Sampling
Jeden einzelnen Request zu tracen erzeugt gigantische Datenmengen (und kostet Performance). Man nutzt daher Sampling:
- Probabilistic Sampling: Trache nur 1% aller Requests.
- Tail-based Sampling: Entscheide erst am Ende der Kette: "War der Request langsam oder gab es Fehler? Wenn ja, speichere den Trace. Wenn alles okay war, wirf ihn weg."
1. Span Events vs. Tags
Profis wissen, wann sie Tags und wann sie Events innerhalb eines Spans nutzen.
- Tags sind Key-Value-Paare für den gesamten Span (
db.system=postgres). Sie sind meist indiziert und durchsuchbar. - Events sind zeitpunktbezogene Logs innerhalb eines Spans (z. B. "Datenbank-Verbindung aufgebaut" bei $T+5ms$). Ein häufiger Fehler ist "Tag Overuse": Wenn man zu viele eindeutige IDs (z. B. User-IDs) in Tags packt, explodiert die Kardinalität im Tracing-Backend (High Cardinality Problem), was die Suche extrem verlangsamt und die Kosten in die Höhe treibt.
2. Clock Skew (Die lügende Zeitachse)
Ein Trace wird aus Spans von verschiedenen Servern zusammengebaut. Wenn Server A glaubt, es ist 12:00:01.000, und Server B (dessen Uhr falsch geht) glaubt, es ist 12:00:00.900, dann sieht es im Trace so aus, als ob die Antwort von B vor der Anfrage von A kam. Traces nutzen oft Relative Timing. Der Koordinator-Service versucht, den Uhrzeit-Versatz (Clock Skew) mathematisch zu korrigieren, indem er die Netzwerklatenz schätzt. Dennoch bleibt dies ein "Heilsversprechen" – für Sub-Millisekunden-Analysen ist Distributed Tracing ohne hochpräzise PTP-Uhren (Precision Time Protocol) oft ungenau.
3. Service Maps & Causality
Moderne Tracing-Tools (wie Datadog oder Dynatrace) berechnen aus Millionen von Traces automatisch eine Service Map. Sie sehen: "A ruft immer B auf". Das ist mächtiger als ein statisches Architektur-Diagramm, weil es die echte Kausalität zur Laufzeit zeigt. Wenn plötzlich Pfeile auftauchen, die es laut Design nicht geben dürfte (z. B. Front-end ruft direkt die User-DB anstatt des User-Service auf), deckt Tracing Architektur-Verstöße und Sicherheitslücken (Access-Bypass) gnadenlos auf.
Quick-Check
Was ist ein Span?
Die kleinste Einheit eines Traces. Er repräsentiert eine einzelne Arbeitseinheit in einem Service (z. B. eine DB-Query). Ein Trace besteht aus vielen (verschachtelten) Spans.Unterschied zu Logs?
Logs sind wie Tagebucheinträge einzelner Personen. Traces sind wie der Bericht eines Detektivs, der einer Person durch die ganze Stadt (alle Services) folgt.Warum ist OpenTelemetry wichtig?
Früher hatte jedes Tool ein eigenes Format. OTel ist der Standard, mit dem du Traces sammeln kannst, ohne dich an einen Anbieter (Vendor Lock-in) zu binden.