Distributed Tracing mit OpenTelemetry: Requests durch Microservices verfolgen

Das Problem: Unsichtbare Request-Pfade

User klickt, Seite ist langsam. Aber wo steckt das Problem? Im API Gateway? Im Auth Service? In der Datenbank? Ohne Distributed Tracing wird Debugging zum Ratespiel.

OpenTelemetry: Der Standard

OpenTelemetry (OTel) ist der CNCF-Standard für Observability-Daten. Es ersetzt proprietäre Lösungen wie Jaeger-Clients und Zipkin-Libraries durch eine einheitliche API.

• Auto-Instrumentation: OTel kann HTTP-Requests, Datenbank-Queries und Message-Queue-Operationen automatisch instrumentieren — ohne Code-Änderungen.
• Context Propagation: Trace-IDs werden automatisch über HTTP-Header und Message-Queue-Metadaten weitergereicht.
• Vendor-neutral: Senden Sie Traces an Jaeger, Tempo, Datadog oder jeden anderen OTel-kompatiblen Backend.

Traces in der Praxis

• Span-Attribute: Reichern Sie Spans mit Business-Kontext an — User-ID, Tenant, Feature-Flag-Status.
• Sampling: In Produktion müssen Sie nicht jeden Request tracen. Head-based Sampling (z.B. 10%) oder Tail-based Sampling (nur Fehler und langsame Requests) reduziert Kosten.
• Korrelation: Verknüpfen Sie Trace-IDs mit Logs und Metriken für vollständige Sichtbarkeit.

Unsere Architektur

Bei devRocks setzen wir auf OTel mit Grafana Tempo als Backend. Der OTel Collector läuft als DaemonSet auf jedem Node und leitet Traces, Metriken und Logs an die jeweiligen Backends weiter — eine Pipeline für alles.