Jaeger vs Zipkin
CNCF distributed tracing versus the original open-source trace aggregation system.
Overview
What is being compared
Zipkin and Jaeger are both distributed tracing backends. Zipkin pioneered distributed tracing and defined many of the trace context propagation standards used today. Jaeger, developed by Uber and donated to CNCF, is a modern tracing system with better scalability, adaptive sampling and Kubernetes-native deployment.
- Origin — Built at Uber, donated to CNCF — The original open-source tracing system
- Sampling — Adaptive, per service and endpoint — Fixed rate or probabilistic
- Deployment — Kubernetes-native, scales further — Simpler to deploy
- Storage — Cassandra, Elasticsearch, Kafka for ingestion — MySQL, Cassandra, Elasticsearch
- Ecosystem fit — CNCF, Prometheus and Grafana — Spring Cloud Sleuth
- OpenTelemetry — Receives OTLP — Receives OTLP
One instrumentation, either backend
Both backends support the OpenTelemetry data model, so the backend choice is increasingly decoupled from how services are instrumented. Services emit spans once, and the Collector decides where they go.
> [!TIP] Instrument with the OpenTelemetry SDK, not a native Jaeger or Zipkin client, so switching backends later needs no code change.
When a trace is kept or dropped
Sampling is where the two differ most: Jaeger adapts rates per service and endpoint, Zipkin applies a fixed or probabilistic rate. Either way, storing every trace from a busy service costs too much, so the keep-or-drop decision happens at one of two moments.
Read left to right: blue is where head-based sampling decides, yellow where tail-based sampling decides, green the result.
> [!TIP] Spans flowing from the OpenTelemetry SDK through the Collector to either backend, one trace followed across an HTTP call and a queue, and the questions that pick Jaeger, Zipkin or Tempo, step by step in Visual Explanation below.
Sign up free to read the full topic
More Comparisons topics
Start free on Cariara · Coding problems · System design studio