Warum einfache Logs nicht mehr reichen
Ein einzelner HTTP-Request landet heute selten auf einem einzigen Server. Hinter einer API-Antwort können Dutzende Microservices stecken: Authentifizierung, Produktdaten, Bestandsprüfung, Zahlungsabwicklung, Benachrichtigungen. Jeder dieser Dienste loggt lokal, aber keiner sieht das vollständige Bild. Wenn eine Antwort fünf Sekunden statt 200 Millisekunden benötigt, liegt die Ursache oft tief im Inneren dieser Kette – und klassische Logs zeigen nur, was auf einem einzelnen Dienst passiert ist, nicht, was den gesamten Ablauf verlangsamt hat.
Distributed Tracing löst genau dieses Problem. Es macht den vollständigen Weg einer Anfrage durch alle beteiligten Dienste sichtbar – mit präzisen Zeitstempeln für jeden Schritt.
Spans und Traces: Die Bausteine des Distributed Tracing
Distributed Tracing basiert auf zwei zentralen Konzepten:
Trace
Ein Trace repräsentiert den vollständigen Lebenszyklus einer Anfrage vom Eingang bis zur Antwort. Jeder Trace erhält eine eindeutige Trace-ID, die durch alle beteiligten Dienste weitergegeben wird. So lassen sich alle Schritte einer Anfrage zu einem vollständigen Bild zusammensetzen – unabhängig davon, auf wie vielen Servern und in wie vielen Sprachen sie ausgeführt wurden.
Span
Ein Span ist die kleinste Einheit innerhalb eines Traces. Er repräsentiert eine einzelne Operation: einen Datenbankaufruf, eine HTTP-Anfrage an einen anderen Service, eine Cache-Abfrage. Jeder Span enthält:
- Eine eindeutige Span-ID
- Die zugehörige Trace-ID
- Start- und Endzeitpunkt (und damit die Dauer)
- Den Namen der Operation
- Optionale Attribute (Tags) und Ereignisse
- Den Status (Erfolg oder Fehler)
Spans können verschachtelt sein: Ein übergeordneter Span (Parent Span) löst untergeordnete Spans (Child Spans) aus. Aus dieser Baumstruktur entsteht ein vollständiges Flamegraph-Diagramm der Anfrage.
Context Propagation: Der Schlüssel zur verteilten Sichtbarkeit
Damit Traces über Servicegrenzen hinweg funktionieren, muss die Trace-ID zusammen mit der Anfrage weitergegeben werden. Dieser Mechanismus heißt Context Propagation. Bei HTTP-Anfragen geschieht das über spezielle Header – etwa traceparent nach dem W3C-Standard oder die proprietären Header älterer Systeme wie Zipkin-B3-Header.
Korrekte Context Propagation ist eine der häufigsten Hürden beim Einführen von Distributed Tracing: Jeder Dienst muss die Trace-ID aus eingehenden Anfragen lesen und an ausgehende Anfragen weitergeben. Vergisst ein Dienst diesen Schritt, bricht die Trace-Kette ab.
OpenTelemetry als einheitlicher Standard
Lange konkurrierten verschiedene proprietäre Tracing-Systeme – Zipkin, Jaeger, AWS X-Ray, Datadog – mit inkompatiblen Formaten und SDKs. OpenTelemetry (OTel) hat dieses Problem weitgehend gelöst: Es bietet ein einheitliches SDK für Traces, Metriken und Logs, das in nahezu allen gängigen Programmiersprachen verfügbar ist.
Mit OpenTelemetry instrumentiert man eine Anwendung einmal – und kann die Telemetriedaten anschließend an beliebige Backends senden. Das Vendor-Lock-in entfällt. OTel ist heute Teil der Cloud Native Computing Foundation (CNCF) und wird von Dutzenden Monitoring-Plattformen nativ unterstützt.
Tracing-Backends: Jaeger und Grafana Tempo
Jaeger
Jaeger ist ein von Uber entwickeltes, quelloffenes Tracing-System. Es bietet eine Weboberfläche, über die Traces nach Service, Operation, Dauer und Fehler gefiltert werden können. Für Teams, die bereits Elasticsearch oder Cassandra betreiben, lässt sich Jaeger direkt in diese Datastores integrieren.
Grafana Tempo
Grafana Tempo ist auf kosteneffiziente Speicherung großer Trace-Mengen ausgelegt. Im Gegensatz zu Jaeger verzichtet Tempo auf eine eigene Indexstruktur und speichert Traces direkt in Objektspeichern wie S3 oder GCS. Die Suche erfolgt über Trace-IDs, die aus anderen Signalen – Logs, Metriken – stammen. In Kombination mit Grafana Loki (Logs) und Prometheus (Metriken) entsteht ein vollständiger Observability-Stack.
Typische Anwendungsfälle für Distributed Tracing
Latenzanalyse
Der häufigste Einsatzzweck: Eine Anfrage dauert unerwartet lange. Mit einem Trace lässt sich exakt bestimmen, welcher Span die meiste Zeit beansprucht hat. Oft liegt die Ursache in N+1-Datenbankabfragen, ungecachten externen API-Aufrufen oder einem überlasteten Microservice.
Fehlerdiagnose
Wenn ein Request mit einem Fehler endet, zeigt der Trace, in welchem Dienst der Fehler entstanden ist und wie er sich durch nachgelagerte Dienste fortgepflanzt hat. Das ist besonders wertvoll, wenn der ursprüngliche Fehler von einem anderen Service als dem antwortenden ausgelöst wurde.
Dependency-Mapping
Aus aggregierten Traces lassen sich automatisch Service-Dependency-Maps erzeugen: Welche Services rufen welche anderen auf? Wie häufig? Mit welcher mittleren Latenz? Diese Karten sind wertvoller als jede manuell gepflegte Architekturdokumentation, weil sie den tatsächlichen, aktuellen Zustand zeigen.
KI-gestützte Trace-Analyse
Die Menge an Trace-Daten in produktiven Microservices-Umgebungen übersteigt schnell die manuelle Analysefähigkeit von Teams. KI-Ansätze helfen auf mehreren Ebenen:
- Anomalieerkennung: Statt absolute Schwellenwerte zu definieren, erkennen ML-Modelle Abweichungen vom typischen Latenzprofil – auch wenn der absolute Wert noch im konfigurierten Grenzbereich liegt.
- Root-Cause-Analyse: LLM-gestützte Systeme können Trace-Muster mit bekannten Fehlerprofilen abgleichen und automatisch Hypothesen über die Fehlerursache generieren.
- Sampling-Optimierung: In Hochlast-Umgebungen können nicht alle Traces gespeichert werden. KI-gestützte Tail-Based-Sampling-Algorithmen entscheiden, welche Traces (besonders interessante Fehler, Ausreißer in der Latenz) vollständig aufbewahrt werden sollen.
Einstieg in die Praxis
Wer Distributed Tracing einführen möchte, sollte mit einem klaren Ziel beginnen: Welches Latenzproblem oder welcher Fehler soll sichtbar gemacht werden? Der vollständige Umbau aller Services auf einmal ist selten sinnvoll. Stattdessen empfiehlt sich ein inkrementeller Ansatz: zunächst die kritischsten oder am schwierigsten debugbaren Services instrumentieren, ein Backend einrichten, erste Traces analysieren – und dann sukzessive erweitern.
OpenTelemetry bietet für die meisten Frameworks Auto-Instrumentation-Bibliotheken, die ohne Code-Änderungen am Anwendungscode bereits grundlegende Traces erzeugen. Das senkt den Einstiegsaufwand erheblich.
Fazit
Distributed Tracing schließt eine Lücke, die Logs und Metriken alleine nicht füllen können: Es macht den vollständigen Weg einer Anfrage durch verteilte Systeme sichtbar. Spans und Traces liefern die zeitliche Auflösung, um Latenzen präzise zu lokalisieren und Fehlerursachen schnell zu identifizieren. Mit OpenTelemetry als standardisierter Grundlage und KI-Unterstützung für die Analyse wird Distributed Tracing auch für Teams ohne spezialisiertes SRE-Know-how zugänglich.
Bildquelle: panumas nikhomkhai / Pexels, Pexels-Lizenz. Das Bild zeigt Server-Racks mit leuchtenden Netzwerkkomponenten in einem modernen Rechenzentrum.
Quellen
- OpenTelemetry-Dokumentation (opentelemetry.io)
- Jaeger-Dokumentation (jaegertracing.io)
- Grafana Tempo-Dokumentation (grafana.com/docs/tempo)
- Google Dapper Paper: Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (2010)
