Distributed Tracing für jeden Request, Ende zu Ende

Was ist Distributed Tracing?

Distributed Tracing zeichnet den Weg eines einzelnen Requests durch ein verteiltes System auf. Jede Arbeitseinheit, etwa ein HTTP-Handler, eine Datenbankabfrage oder das Publizieren einer Nachricht, wird zu einem Span mit Startzeit, Dauer und Attributen. Alle Spans teilen sich eine Trace-ID und verweisen auf ihren Parent. Zusammen ergeben sie einen Baum, der zeigt, wo Zeit verbraucht wurde und wo ein Fehler entstanden ist.

In einem Monolithen reichen oft ein Stack Trace oder ein Profiler. In einer Microservices-Architektur berührt ein einziger Checkout-Request dagegen ein API-Gateway, fünf Services, zwei Datenbanken, einen Cache und eine Message Queue. Metriken zeigen, dass die Latenz steigt, Logs zeigen einzelne Ereignisse. Erst der Trace verbindet beides zu einer kausalen Geschichte für genau diesen Request.

Warum Distributed Tracing für Microservices unverzichtbar ist

Moderne Systeme fallen selten auf einem einzelnen Host aus. Eine langsame Abhängigkeit löst Retries im Upstream aus, ein falsch konfigurierter Connection Pool staut Requests, eine neue Version bringt eine N+1-Query mit. Ohne Tracing springen Engineers zwischen Dashboards und gleichen Zeitstempel von Hand ab. Das kostet Zeit und treibt die MTTR nach oben.

• Latenz zuordnen: Sehen Sie, welcher Span auf dem kritischen Pfad am meisten zur Gesamtdauer beiträgt.
• Fehlerursprung finden: Erkennen Sie den Service, in dem eine Exception zuerst auftrat, nicht nur den Rand, an dem ein 500 zurückkam.
• Abhängigkeiten verstehen: Reale Aufrufmuster, Fan-out und Retries statt veralteter Architekturdiagramme.
• Releases verifizieren: Vergleichen Sie Traces vor und nach einem Deployment und bestätigen Sie, dass sich die Änderung wie erwartet verhält.

Welche Signale Sie in Traces auswerten sollten

Ihren vollen Wert entfalten Traces erst in der Aggregation. Span-Daten passen direkt zur RED-Methode: Rate der Requests, Errors und Duration pro Service und Endpoint. Darüber hinaus lohnen sich folgende Fragen:

• Welche Endpoints haben die schlechteste p95- und p99-Latenz, und welche Spans dominieren diese langsamen Traces?
• Wie unterscheidet sich die Latenz nach Attributen wie Mandant, Region, Client-Version oder Feature Flag?
• Wo häufen sich Retries, Timeouts und Circuit-Breaker-Ereignisse?
• Welche Datenbank-Statements oder externen API-Calls tauchen am häufigsten in langsamen Traces auf?

Mit OQL beantworten Sie solche Fragen direkt auf Span-Daten, zum Beispiel mit fetch spans | filter service == "checkout" and duration > 500ms | summarize count(), by:{span.name}.

So funktioniert Distributed Tracing mit Obseria

Obseria ist OpenTelemetry-nativ. Sie senden OTLP aus vorhandenen SDKs und Collectors oder lassen den Obseria Agent gängige Runtimes automatisch instrumentieren. Die Traces landen in Obseria Lake, einem indexfreien Lakehouse mit Schema-on-Read. Jedes Span-Attribut bleibt abfragbar, ohne dass Sie vorab Indizes definieren müssen.

Obseria Pipeline arbeitet direkt beim Ingest: Sie wendet Tail-based Sampling an, sodass vollständige Traces mit Fehlern oder hoher Latenz erhalten bleiben, reichert Spans mit Kubernetes-, Cloud- und Deployment-Metadaten an und maskiert personenbezogene Daten. Obseria TopoGraph baut aus denselben Spans eine Live-Service-Map. Obseria Intelligence kombiniert Topologie und Traces zu agentischen Ursachenanalysen, die eine nachvollziehbare Beweiskette liefern statt einer Vermutung.

Jeder Trace ist mit Logs, Metriken und Continuous Profiles verknüpft. So gelangen Sie von einem langsamen Span direkt zur Funktion, die die CPU-Zeit verbraucht hat. Da das Datenmodell offen ist, können Sie Traces jederzeit per OTLP exportieren.

Für den Einstieg brauchen Sie keine Migration: Bestehende Collector-Pipelines bleiben erhalten, Sie ergänzen lediglich Obseria als Ziel. So können Sie Tracing zunächst für einzelne Services aktivieren und schrittweise auf die gesamte Landschaft ausweiten, ohne dass Ihre Teams ihre gewohnten Werkzeuge aufgeben müssen.

Best Practices für Distributed Tracing

1. Mit Auto-Instrumentierung starten und anschließend manuelle Spans um geschäftskritische Operationen wie die Zahlungsautorisierung ergänzen.
2. Kontext überall weitergeben, auch über asynchrone Grenzen wie Queues und Background Jobs, damit Traces nicht abreißen.
3. Semantic Conventions nutzen, damit Dashboards und Abfragen teams- und sprachübergreifend funktionieren.
4. Fachliche Attribute ergänzen, etwa Tarif, Mandant oder Bestelltyp, um technische Performance mit Geschäftsauswirkung zu verbinden.
5. Intelligent sampeln: Tail-based Sampling ist festem Head Sampling vorzuziehen, damit seltene Fehler nie verloren gehen.
6. Sensible Daten aus Spans fernhalten: Maskieren Sie personenbezogene Daten zentral beim Ingest, statt sich auf jede einzelne Codezeile zu verlassen.