Warum klassisches Monitoring nicht mehr ausreicht
Wer eine monolithische Anwendung betreibt, kommt mit Uptime-Checks, CPU-Graphen und Fehlerprotokollen gut zurecht. Sobald eine Architektur aber aus Dutzenden oder Hunderten von Microservices besteht – ergänzt durch externe KI-APIs, Message-Queues und serverlose Komponenten – entstehen blinde Flecken, die kein klassisches Monitoring aufdecken kann. Eine Anfrage, die in der Datenbank langsam ist, erscheint im Dashboard des API-Gateways möglicherweise als Netzwerkproblem. Das ist das Problem, das Distributed Tracing löst.
Und mit OpenTelemetry steht seit einigen Jahren ein offener, herstellerunabhängiger Standard bereit, der genau dieses Ziel adressiert: Alle Komponenten eines verteilten Systems einheitlich zu instrumentieren und die Telemetriedaten – Traces, Metriken und Logs – zusammenzuführen.
Was Distributed Tracing eigentlich bedeutet
Der Kerngedanke ist einfach: Jede eingehende Anfrage erhält beim Eintritt ins System eine eindeutige Trace-ID. Diese ID wird über alle beteiligten Services weitergegeben – per HTTP-Header, Message-Queue-Metadaten oder RPC-Kontext. Jeder Service, der an der Verarbeitung beteiligt ist, erstellt einen sogenannten Span: einen Datenpunkt, der Startzeit, Endzeit, Fehlerstatus und relevante Metadaten für genau diesen Verarbeitungsschritt enthält.
Am Ende ergibt sich ein vollständiger Stammbaum der Anfrage – ein sogenannter Trace. Dieser zeigt, welche Services beteiligt waren, wie lange jeder Schritt dauerte und wo Fehler oder Latenzen aufgetreten sind.
OpenTelemetry: Der offene Standard
OpenTelemetry (OTel) entstand 2019 aus der Fusion von OpenCensus (Google) und OpenTracing (CNCF). Heute ist es das meistgenutzte Framework zur Instrumentierung von Observability-Daten und wird von allen großen Cloud-Providern, APM-Anbietern und Observability-Plattformen unterstützt.
Die wichtigsten Konzepte
- SDK und API: OpenTelemetry bietet SDKs für die gängigsten Programmiersprachen – Go, Java, Python, Node.js, .NET, Rust und mehr. Damit wird Code direkt instrumentiert.
- Auto-Instrumentation: Für viele Frameworks und Libraries existieren Plugins, die ohne Code-Änderungen Spans erzeugen – etwa für HTTP-Clients, Datenbankverbindungen oder Message-Broker.
- Collector: Der OpenTelemetry Collector ist ein eigenständiger Prozess, der Telemetriedaten empfängt, verarbeitet, filtert und an verschiedene Backends weiterleitet. Er entkoppelt die Instrumentierung von der Speicherentscheidung.
- OTLP: Das OpenTelemetry Protocol (OTLP) ist das standardisierte Übertragungsformat, das von praktisch allen modernen Observability-Backends verstanden wird.
Distributed Tracing für KI-APIs: Ein wachsender Anwendungsfall
Mit der zunehmenden Integration von KI-APIs – etwa von Anthropic, OpenAI oder Google – entstehen neue Anforderungen ans Tracing. Ein typischer Workflow könnte so aussehen: Eine Nutzeranfrage trifft ein Backend-Service, der intern zuerst einen Vektor-Datenbank-Lookup macht, dann eine LLM-API aufruft, anschließend das Ergebnis verarbeitet und zurückgibt.
Ohne Tracing ist unklar: Wo liegt die Latenz? Im Datenbankzugriff? Im LLM-API-Call? In der Nachverarbeitung? Mit korrekt gesetzten Spans sieht das Team sofort, dass etwa 85 % der Antwortzeit auf den KI-API-Call entfallen – und kann gezielt optimieren, cachen oder eine schnellere Modellvariante testen.
Nützliche Attribute für KI-Spans
Beim Instrumentieren von LLM-Aufrufen empfiehlt es sich, folgende Attribute als Span-Attribute zu erfassen:
- Verwendetes Modell (z. B.
llm.model = claude-sonnet-4-5) - Anzahl der Input- und Output-Token (
llm.usage.input_tokens,llm.usage.output_tokens) - HTTP-Statuscode der API-Antwort
- Latenz des gesamten API-Calls
- Fehlerdetails bei Timeouts oder Rate-Limits
Diese Daten ermöglichen nicht nur Latenz-Debugging, sondern auch Token-Kosten-Analysen auf Anfrage-Ebene.
Praxistipps für die Einführung
Schrittweise vorgehen
Vollständige Instrumentierung eines großen Systems auf einen Schlag ist unrealistisch. Empfehlenswert ist ein Ansatz von außen nach innen: Zunächst das API-Gateway oder den Load-Balancer instrumentieren, dann die kritischsten Backend-Services, zuletzt die internen Datenbank- und Cache-Verbindungen.
Sampling sinnvoll konfigurieren
In Systemen mit hohem Durchsatz erzeugt 100-%-Tracing erhebliche Kosten. Head-based Sampling entscheidet beim Eingang einer Anfrage, ob sie komplett getract wird. Tail-based Sampling hingegen entscheidet nach dem Abschluss der Anfrage – und kann gezielt Fehler oder langsame Anfragen immer erfassen, auch wenn der Rest gesampelt wird.
Logs mit Traces verknüpfen
Wenn Log-Einträge die Trace-ID und Span-ID enthalten, können Support-Teams direkt aus einem Fehler-Log in den zugehörigen Trace springen. Das spart enorme Zeit bei der Fehlersuche. Die meisten modernen Log-Frameworks unterstützen diese Verknüpfung nativ oder per Middleware.
Alerting auf Trace-Daten aufbauen
Trace-Daten eignen sich nicht nur zur Analyse, sondern auch als Grundlage für Alerts. Wenn die p95-Latenz eines bestimmten Services innerhalb eines definierten Zeitfensters überschritten wird oder die Fehlerrate einer LLM-API-Integration steigt, sollten diese Anomalien unmittelbar als Alert verarbeitet werden.
Backends und Tools im Ökosystem
OpenTelemetry-Daten können an zahlreiche Backends gesendet werden:
- Jaeger und Zipkin: Klassische Open-Source-Tracing-Backends
- Grafana Tempo: Skalierbares Tracing-Backend, das gut mit Prometheus und Loki kombiniert werden kann
- Elastic APM: Integration in den Elastic-Stack für kombinierte Logs-und-Traces-Analyse
- Datadog, New Relic, Honeycomb: Kommerzielle Plattformen mit nativem OTel-Support
Fazit: Tracing ist keine Option mehr
In modernen Architekturen, die auf Microservices und externe KI-APIs setzen, ist Distributed Tracing keine Nice-to-have-Funktion, sondern ein operatives Muss. OpenTelemetry liefert dafür einen stabilen, offenen Standard, der zukünftige Anbieterwechsel erleichtert und heute von allen relevanten Plattformen unterstützt wird. Teams, die jetzt in vernünftige Trace-Instrumentierung investieren, erhalten Einblicke, die klassisches Monitoring schlicht nicht liefern kann.
Bildquelle: Pexels.com – Negative Space, lizenzfrei (Pexels License)
Quellen
- OpenTelemetry Dokumentation: opentelemetry.io
- CNCF Landscape: Distributed Tracing Kategorie
- OpenTelemetry Semantic Conventions für LLM-Spans: opentelemetry.io/docs/specs/semconv
