principlejavascriptTip
Jaeger vs Zipkin: choosing a distributed tracing backend
Viewed 0 times
Jaeger v2, Grafana Tempo ^2.x
JaegerZipkinGrafana TempoOTLPtracing backendobject storage tracestail-based samplingJaeger Operator
Problem
Teams starting with distributed tracing don't know whether to use Jaeger or Zipkin, and may make architectural decisions that are hard to reverse after traces are flowing at scale.
Solution
Both are open-source distributed tracing backends that support OpenTelemetry. With OTel, the choice is largely reversible since the OTLP exporter can be pointed at either.
Jaeger:
Zipkin:
Grafana Tempo (modern alternative):
For new projects: use Grafana Tempo if on Grafana, otherwise Jaeger. Zipkin is primarily for legacy compatibility.
Jaeger:
- Native OTLP support in Jaeger v2
- Better UI for trace comparison and service dependency graphs
- Supports Cassandra, Elasticsearch, and in-memory storage
- Better Kubernetes-native deployment story (Jaeger Operator)
Zipkin:
- Older, simpler, less feature-rich UI
- JSON-over-HTTP protocol widely supported
- Lighter weight for simple setups
Grafana Tempo (modern alternative):
- Stores traces cheaply in object storage (S3, GCS)
- Integrates natively with Grafana, Loki, and Prometheus
- Best choice for teams already on the Grafana stack
For new projects: use Grafana Tempo if on Grafana, otherwise Jaeger. Zipkin is primarily for legacy compatibility.
Why
OpenTelemetry's vendor-neutral OTLP protocol means the tracing backend is interchangeable — invest more in good instrumentation than in backend selection.
Gotchas
- Jaeger v1 uses its own wire format — Jaeger v2 switched to native OTLP, prefer v2 for new deployments
- Both backends need persistent storage for production — in-memory storage drops traces on restart
- Tempo does not support search by arbitrary tags without an index (Tempo search is sampling-based by default)
- Trace retention is expensive at high volume — implement head-based or tail-based sampling
Context
Choosing a distributed tracing backend for a new observability stack
Revisions (0)
No revisions yet.