Jaeger
Open-Source-Distributed-Tracing-System – verfolgt Request-Pfade durch verteilte Systeme und macht Latenzbottlenecks sichtbar.
Aktualisiert: 23. Februar 2026
Was ist Jaeger?
Jaeger ist ein Open-Source-Distributed-Tracing-System, das ursprünglich von Uber Technologies entwickelt und 2017 als CNCF-Projekt (Cloud Native Computing Foundation) gespendet wurde. Es implementiert den OpenTracing-Standard und ist heute OpenTelemetry-kompatibel. Jaeger verfolgt, wie ein eingehender Request durch verschiedene Dienste und Komponenten fließt — und misst, wie lange jeder einzelne Schritt dauert.
Für Webseitenbetreiber mit mehrschichtigen Stacks (Nginx → PHP-FPM → WordPress → MySQL + Redis) beantwortet Jaeger Fragen, die mit Logs und Metriken allein nicht zu beantworten sind: Welcher Dienst ist schuld, wenn ein Request 800ms dauert statt 100ms? Ist es die Datenbankabfrage, der Redis-Cache-Miss oder der PHP-Code?
Kurzprofil Jaeger
- Typ: Distributed Tracing System
- Entwickelt von: Uber Technologies (2015), heute CNCF-Projekt
- Lizenz: Apache 2.0
- Standard: OpenTelemetry (OTLP), früher OpenTracing
- Komponenten: Jaeger Collector, Query, Agent, UI
- Storage-Backends: Elasticsearch, OpenSearch, Cassandra, Badger (eingebettet)
- Integration: Grafana (als Datenquelle), OpenTelemetry SDKs
Wie funktioniert Distributed Tracing?
Jeder Request bekommt eine eindeutige Trace-ID. Wenn der Request durch verschiedene Dienste fließt, propagiert jeder Dienst diese ID in ausgehenden HTTP-Requests oder Datenbankabfragen. Jeder Schritt erzeugt einen Span — einen Zeitstempel-geklammerten Abschnitt mit Start, Ende und Metadaten.
Das Ergebnis ist ein Trace: ein hierarchischer Baum von Spans, der den gesamten Request-Pfad visualisiert:
Trace: GET /wp-json/wp/v2/posts (total: 820ms)
├── nginx reverse proxy (2ms)
├── PHP-FPM worker (815ms)
│ ├── WordPress bootstrap (45ms)
│ ├── MySQL query: SELECT * FROM wp_posts (380ms) ← Bottleneck!
│ ├── Redis get: post_cache_123 (1ms)
│ └── Template rendering (389ms)
└── Response compression (3ms)
In diesem Beispiel zeigt Jaeger, dass die MySQL-Abfrage 380ms dauert — obwohl der gesamte Request 820ms braucht. Ohne Tracing würde man nur "langsam" sehen, nicht wo.
Jaeger für WordPress-Betreiber
Für WordPress ist die Einbindung von OpenTelemetry (das Jaeger als Backend nutzen kann) über PHP-Libraries möglich:
OpenTelemetry PHP SDK:
use OpenTelemetry\SDK\Trace\TracerProvider;
use OpenTelemetry\Contrib\Otlp\OtlpHttpTransport;
$transport = new OtlpHttpTransport('http://jaeger:4318/v1/traces');
$tracerProvider = new TracerProvider(/* ... exporters ... */);
Ein Plugin oder mu-plugin kann so automatisch alle WordPress-Hooks, MySQL-Abfragen und Cache-Zugriffe instrumentieren und als Spans an Jaeger schicken.
Grafana Tempo als Alternative:Grafana Tempo ist ein weiteres Open-Source-Tracing-Backend, das tiefer in den Grafana-Stack integriert ist und häufig als modernere Alternative zu Jaeger eingesetzt wird. Beide sind OpenTelemetry-kompatibel.
Jaeger einsetzen
- All-in-One-Container für Entwicklung:
docker run -p 16686:16686 -p 4317:4317 jaegertracing/all-in-one - Jaeger UI: http://localhost:16686 — Trace-Suche, Service-Graph, Flame-Grafik
- WordPress: OpenTelemetry PHP SDK + auto-instrumentation für MySQL und HTTP
- Grafana: Jaeger als Datenquelle einbinden für Trace-Korrelation mit Metriken und Logs
- Produktion: Elasticsearch als Storage-Backend für längere Trace-Retention
- Sampling: Nicht alle Requests tracen (zu viel Storage) — 1–10 % Sampling reicht für Analyse
Was passiert ohne Tracing?
Ohne Distributed Tracing bleibt bei Latenzen unklar, welcher Dienst die Ursache ist. Prometheus-Metriken zeigen, dass MySQL langsam ist — aber nicht welche Query. Logs zeigen Fehler — aber nicht den Request-Kontext. Tracing schließt diese Lücke und macht Optimierungen zielgerichtet statt spekulativ.
Häufige Fragen
Jaeger vs. Zipkin — was ist der Unterschied? Beide sind Distributed-Tracing-Systeme. Zipkin (von Twitter, 2012) ist älter und einfacher. Jaeger (von Uber, 2015) ist umfangreicher, hat eine bessere UI und ist OpenTelemetry-nativer. Für neue Setups ist Jaeger oder Grafana Tempo die modernere Wahl.
Wie viel Overhead erzeugt Tracing? Bei 1–10 % Sampling-Rate ist der Overhead für die Applikation typischerweise unter 1 %. Die Instrumentierung selbst erzeugt messbare CPU-Zeit, aber in der Praxis selten über 2–5 % bei normalen Web-Workloads.
Verwandte Begriffe
OTLP · OpenTelemetry