Warum Distributed Tracing?

In einer Microservices-Architektur ist ein einzelner Request oft ein Weg durch 5–20 Services. Wenn etwas langsam ist oder fehlschlägt, braucht du Tracing: eine Visualisierung des kompletten Pfades eines Requests durch alle beteiligten Services, mit Timings, Fehlern und Metadaten.

Grafana Tempo und Jaeger sind die beiden dominierenden Open-Source-Backends für Distributed Tracing. Beide funktionieren mit OpenTelemetry – dem modernen Standard für Telemetry-Daten.

Jaeger: Das CNCF-Urgestein

Jaeger wurde 2016 von Uber entwickelt und 2017 an die CNCF gespendet. Es ist eines der ersten ernsthaften Distributed-Tracing-Systeme und battle-tested in großen Produktionsumgebungen.

Architektur

Jaeger besteht aus mehreren Komponenten:

Anwendung (OTLP/Jaeger-Protocol)
  → Jaeger Collector
    → Elasticsearch / Cassandra / BadgerDB (Storage)
  → Jaeger Query UI (Frontend)

Jaeger mit Elasticsearch ist der klassische Production-Stack. Cassandra wird für sehr hohe Durchsatzanforderungen genutzt. BadgerDB ist ein eingebettetes Storage für kleinere Setups.

Stärken von Jaeger

Reifer, Battle-Tested: Jaeger läuft seit Jahren in Produktionsumgebungen bei Uber, Netflix, IBM und vielen anderen. Die Community ist groß.

Native Jaeger UI: Jaeger hat eine eingebaute Trace-Visualisierung, die für einfachere Setups ausreicht. Sie erlaubt:

  • Trace-Suche nach Service, Operation, Tags
  • Gantt-Chart-Darstellung von Traces
  • Service Dependency Graph

Protocol-Unterstützung: Jaeger unterstützt OpenTelemetry, Jaeger Native, Zipkin und Thrift – du kannst von bestehenden Setups migrieren ohne Code-Änderungen.

OTLP-kompatibel (Jaeger v1.35+): Seit Version 1.35 kann Jaeger OTLP-Daten direkt empfangen, ohne einen separaten OpenTelemetry Collector.

Schwächen von Jaeger

Storage-Probleme: Jaeger ist auf elastische Backends wie Elasticsearch angewiesen, was den Ressourcenbedarf erheblich erhöht. Ein Elasticsearch-Cluster für Traces ist keine triviale Aufgabe.

UI-Limitsierungen: Die Jaeger UI ist funktional, aber im Vergleich zu Grafana eingeschränkt. Alerting, Dashboards oder Metriken gibt es nicht.

Komplexerer Betrieb: Mehrere Komponenten (Collector, Query, Storage) bedeuten mehr Kubernetes-Manifeste und mehr Fehlerquellen.

Grafana Tempo: Cloud-Native und Object-Storage-First

Grafana Tempo wurde 2020 von Grafana Labs entwickelt mit einem klaren Design-Ziel: niedrige Kosten durch Object Storage.

Architektur

Anwendung (OTLP)
  → Grafana Alloy / OpenTelemetry Collector
    → Tempo
      → S3 / GCS / Azure Blob / MinIO (Speicher)
  → Grafana (Visualisierung)

Tempo speichert Traces direkt in Object Storage. Das bedeutet: sehr niedrige Kosten (S3 oder MinIO), unbegrenzte Skalierung und keine Elasticsearch-Komplexität.

Stärken von Grafana Tempo

Object Storage als Backend: Tempo nutzt S3, Google Cloud Storage, Azure Blob oder MinIO für die Speicherung. Das ist:

  • Günstig (S3 kostet ~$0,023/GB/Monat)
  • Skalierbar (kein Kapazitätsplanung)
  • Einfach zu betreiben

Grafana-Integration: Wer bereits Grafana nutzt, bekommt Tracing nahtlos integriert. Mit Grafana Explore kannst du zwischen Logs (Loki), Metriken (Prometheus) und Traces (Tempo) wechseln und sie miteinander verknüpfen.

# Beispiel: Von Prometheus-Metrik zu Trace navigieren
# trace_id in Logs → direkt zu Tempo springen
# aus Tempo → zu Loki-Logs für gleichen Service

Trace-to-Logs Korrelation: Tempo kann automatisch Links zu Loki-Logs erstellen – wenn du einen langsamen Trace siehst, springst du direkt in die korrespondierenden Logs.

Schlanker Betrieb (Monolithic Mode): Für kleinere Setups läuft Tempo als einzelner Container:

# docker-compose.yml
tempo:
  image: grafana/tempo:latest
  volumes:
    - ./tempo-config.yaml:/etc/tempo.yaml
    - tempo-data:/var/tempo
  command: -config.file=/etc/tempo.yaml

Metric Generator: Tempo kann automatisch Metriken aus Traces generieren – z.B. Request-Rate, Fehlerrate und Latenz pro Service, ohne dass du Prometheus-Metriken manuell instrumentieren musst.

Schwächen von Grafana Tempo

Abhängigkeit von Grafana: Ohne Grafana ist Tempo weniger nützlich. Es gibt kein eigenes Frontend – alle Visualisierungen passieren in Grafana.

Neueres Projekt: Tempo ist seit 2020, Jaeger seit 2016. Der Reifegrad und die Community sind noch kleiner.

Object Storage Latenzen: Der Zugriff auf Object Storage ist langsamer als auf lokale SSDs. Für sehr interaktive Trace-Suchen kann das spürbar sein.

Direkter Vergleich

Kriterium Grafana Tempo Jaeger
Storage Backend S3 / MinIO / GCS Elasticsearch / Cassandra
Storage-Kosten Niedrig (Object Storage) Höher (ES-Cluster)
Eigene UI Nein (braucht Grafana) Ja (Jaeger UI)
Grafana-Integration Nativ ✓ Via Plugin
OTLP-Support ✓ ✓ (ab v1.35)
Trace-to-Logs ✓ (Loki) Manuell konfigurierbar
Metric Generator ✓ ✗
Reife 2020 2016
Betrieb Einfacher Komplexer
Kubernetes-Operator ✓ (Tempo Operator) ✓ (Jaeger Operator)

OpenTelemetry als gemeinsame Basis

Beide Backends sind mit OpenTelemetry kompatibel. Das ist wichtig: Für die Instrumentierung deiner Anwendung macht es keinen Unterschied, ob du Tempo oder Jaeger nutzt.

// Go: OpenTelemetry SDK (gleich für Tempo und Jaeger)
tp := trace.NewTracerProvider(
    trace.WithBatcher(otlptracehttp.NewExporter(...)),
)
otel.SetTracerProvider(tp)

Nur das Backend und die OTLP-Endpoint-URL ändern sich. Das erleichtert Migrationen erheblich.

Empfehlung

Grafana Tempo wählen, wenn:

  • Du bereits Grafana + Loki + Prometheus betreibst
  • Du Kosten sparen willst (MinIO statt Elasticsearch)
  • Du Trace-to-Logs-Korrelation nutzen willst
  • Du einen schlanken, modernen Stack bevorzugst

Jaeger wählen, wenn:

  • Du kein Grafana betreibst und eine eigene Tracing-UI brauchst
  • Du bereits Elasticsearch in deiner Infrastruktur hast
  • Du auf erprobte Reife und große Community setzt
  • Du Zipkin-kompatible Clients hast, die du integrieren willst

Für die meisten Kubernetes-Self-Hoster, die bereits im Grafana-Ökosystem sind, ist Grafana Tempo die modernere und günstigere Wahl.

Weiterführende Artikel

Verwandte Technologien im Techradar