In einem einzelnen System genügt ein Blick ins Log, um eine Störung einzugrenzen. Sobald eine Anfrage jedoch drei, fünf oder zehn Komponenten durchläuft — Anwendung, Warteschlange, Datenbank, externe Schnittstelle — versagt dieser Ansatz. Jedes System sieht nur seinen eigenen Ausschnitt und meldet ihn als unauffällig. Der Nutzer wartet trotzdem sechs Sekunden. Distributed Tracing schließt genau diese Lücke.
Die drei Bausteine
Ein Trace ist der vollständige Weg einer einzelnen Anfrage durch alle beteiligten Systeme. Er trägt eine eindeutige Kennung, die von Anfang bis Ende erhalten bleibt. Ein Span ist ein einzelner Arbeitsschritt innerhalb dieses Wegs — ein Datenbankaufruf, eine Berechnung, ein Aufruf einer fremden Schnittstelle. Jeder Span kennt seinen Vorgänger, wodurch eine Baumstruktur entsteht. Die Kontextweitergabe sorgt dafür, dass die Trace-Kennung bei jedem Übergang zwischen Systemen mitwandert, üblicherweise über standardisierte Kopfzeilen im Aufruf.
Aus diesen drei Elementen entsteht eine Darstellung, die eine Anfrage als Zeitachse zeigt: Welcher Schritt hat wann begonnen, wie lange gedauert, und welche Schritte liefen parallel. Damit werden Fragen beantwortbar, die vorher nur Vermutungen zuließen.
Was sofort sichtbar wird
- Serielle Aufrufe, die parallel laufen könnten: Drei unabhängige Abfragen nacheinander summieren ihre Wartezeiten. Im Trace ist das eine Treppe statt eines Blocks.
- Wiederholte Abfragen in Schleifen: Wenn ein einzelner Request hunderte nahezu identische Datenbank-Spans erzeugt, liegt ein klassisches Abfrageproblem vor.
- Wartezeit statt Rechenzeit: Ein Span, der lange dauert, aber keine Unter-Spans hat, wartet auf etwas — Sperre, Verbindungspool oder externe Antwort.
- Fremde Systeme als Engpass: Erst der Trace belegt, dass die Zeit außerhalb der eigenen Anwendung verloren geht. Ohne diesen Beweis wird intern optimiert, wo nichts zu gewinnen ist.
Der häufigste Erkenntnisgewinn ist unspektakulär und teuer: Nicht der komplexe Algorithmus kostet die Antwortzeit, sondern eine Kette wartender Aufrufe, die niemand als Kette gesehen hat.
Standardisierung statt Eigenbau
Für Instrumentierung und Datenformat existiert mit OpenTelemetry ein herstellerunabhängiger Standard. Der praktische Vorteil ist weniger technischer als strategischer Natur: Die Instrumentierung im eigenen Code bleibt bestehen, auch wenn das auswertende Backend gewechselt wird. Wer stattdessen die proprietären Bibliotheken eines Anbieters tief in die Anwendung einbaut, erzeugt eine Abhängigkeit, die sich später nur mit erheblichem Aufwand lösen lässt.
Ein großer Teil der Instrumentierung entsteht dabei automatisch. Verbreitete Webframeworks, Datenbanktreiber und Warteschlangen-Bibliotheken werden ohne eigenen Code erfasst. Manuelle Spans lohnen sich dort, wo fachliche Schritte sichtbar werden sollen — etwa eine Preisberechnung oder eine Bonitätsprüfung.
Sampling: die Kostenfrage
Jede aufgezeichnete Anfrage erzeugt Daten, Übertragung und Speicherkosten. Bei hohem Durchsatz ist eine vollständige Erfassung wirtschaftlich selten sinnvoll. Zwei Strategien sind gebräuchlich: Beim Sampling zu Beginn wird schon am Eingang entschieden, ob eine Anfrage erfasst wird — einfach, aber blind gegenüber später auftretenden Fehlern. Beim Sampling am Ende wird der vollständige Trace zunächst gesammelt und erst danach entschieden — teurer im Betrieb, dafür bleiben Fehlerfälle und Ausreißer sicher erhalten.
Entscheidend ist in beiden Fällen die Konsistenz: Wird ein Trace teilweise erfasst und teilweise verworfen, entstehen Lücken, die schlimmer sind als gar keine Daten, weil sie zu falschen Schlüssen führen.
Was bei der Einführung schiefgeht
Drei Fehler wiederholen sich. Erstens die unterbrochene Kontextweitergabe: Sobald eine Komponente die Trace-Kennung nicht weiterreicht — häufig bei asynchroner Verarbeitung über Warteschlangen — zerfällt der Trace in unverbundene Fragmente. Zweitens personenbezogene oder vertrauliche Daten in Span-Attributen; Traces landen in Systemen mit anderen Zugriffsrechten als die Anwendung selbst, weshalb Attribute bewusst zu wählen sind. Drittens die Erwartung, Tracing ersetze Metriken und Alarmierung. Es ergänzt sie: Metriken melden, dass etwas nicht stimmt, wie bei der klassischen Überwachung und Alarmierung; der Trace erklärt anschließend, warum.
Sinnvoll ist ein schmaler Einstieg: ein einziger geschäftskritischer Pfad, vollständig instrumentiert, über alle beteiligten Systeme hinweg. Ein durchgängiger Trace über eine wichtige Strecke ist mehr wert als lückenhafte Instrumentierung überall.
Vom Einzelfall zur Auswertung über die Zeit
Ein einzelner Trace erklärt einen konkreten Vorfall. Der eigentliche Wert entsteht, wenn viele Traces gemeinsam betrachtet werden. Dann lassen sich Fragen beantworten, die im Tagesgeschäft regelmäßig gestellt und selten belegt werden: Welche Abhängigkeit verursacht die meiste Wartezeit über alle Anfragen hinweg? Hat sich die Antwortzeit nach dem letzten Deployment verschlechtert? Welcher Endpunkt ist am stärksten von einem fremden System abhängig?
Damit diese Auswertung möglich ist, müssen Spans einheitlich benannt und mit denselben Attributen versehen sein. Uneinheitliche Bezeichnungen sind der Hauptgrund, warum Tracing-Daten zwar vorhanden, aber nicht auswertbar sind. Eine kurze, verbindliche Konvention für Namen und Attribute — festgelegt bevor die zweite Komponente instrumentiert wird — spart später erhebliche Nacharbeit.
Ein pragmatischer Einführungspfad
- Schritt eins: Den wichtigsten Geschäftsvorgang auswählen — dort, wo Ausfälle unmittelbar Geld kosten.
- Schritt zwei: Automatische Instrumentierung in allen beteiligten Komponenten aktivieren und die Kontextweitergabe an jedem Übergang prüfen, auch über Warteschlangen hinweg.
- Schritt drei: Wenige manuelle Spans für fachlich relevante Schritte ergänzen, damit Traces auch ohne Systemkenntnis lesbar sind.
- Schritt vier: Sampling und Aufbewahrungsdauer bewusst festlegen, statt Standardwerte zu übernehmen und die Kosten später zu entdecken.
Nach diesen vier Schritten liegt eine belastbare Grundlage vor. Alles Weitere — zusätzliche Dienste, feinere Attribute, Verknüpfung mit Logs — lässt sich schrittweise ergänzen, ohne dass die bereits gewonnene Sichtbarkeit verloren geht.