The tracing backend behind your traces, in plain English, and where OpenTelemetry fits.
If distributed tracing tells you where a request spent its time, Jaeger is one of the places those traces go to live. It is a tracing backend, and since v2 it is built directly on OpenTelemetry.
How the open-source observability stack fits together. Jaeger owns traces here.
What is Jaeger?
Jaeger is an open-source, end-to-end distributed tracing platform: it receives traces, stores them, and gives you a UI to search and visualise a request's journey across services. It came out of Uber, and it was one of the very first projects to graduate from the CNCF. It is a backend, not instrumentation: you produce traces with OpenTelemetry, and Jaeger is where you send them to query and view.
Jaeger v2 and OpenTelemetry
This is the big recent change. Jaeger v2, released in November 2024, is built on the OpenTelemetry Collector itself: one streamlined binary that speaks the OpenTelemetry Protocol end to end, with no translation layer. Jaeger v1 is being retired, with the last v1 release in December 2025 and full deprecation in January 2026. If you are starting today, you are starting on OTel.
What it does well
Purpose-built trace views. Timeline and dependency views that make a slow, multi-service request legible.
Open and standard. OTLP-native and CNCF-graduated, so it fits the wider ecosystem rather than fencing you in.
Focused. It does one job, tracing, and does it well, which keeps it simple to stand up.
From the trenches
Standing up Jaeger is the easy part. Running the storage behind it is where the real work lives, because Jaeger itself does not keep your traces; it hands them to Cassandra or Elasticsearch, and each comes with a bill. Cassandra is quick for pulling a trace by its ID but weak at search, and Jaeger writes extra index entries for service names, operations and every tag, so write amplification is real and storage climbs at roughly a gigabyte or more per million spans. Elasticsearch searches far better but is resource-hungry, and teams have hit hard ceilings: one reported ingesting only about a tenth of the ten terabytes of traces a day their applications produced, for the money they were spending.
Underneath all of it sits sampling. Keep every trace and the storage problem above gets worse fast; sample too hard and you risk dropping the rare failure you most wanted to see. The honest framing is that Jaeger is a fine, standard place to view traces, and the engineering effort is in the backend and the sampling policy, not the tool.
The honest ledger
It is a backend, not the whole story. Jaeger stores and shows traces. You still instrument with OpenTelemetry, and you still need a storage backend such as Cassandra or Elasticsearch behind it.
Traces alone are not observability. You will correlate with metrics and logs to find root cause. Jaeger is the trace piece, not the full picture.
Sampling decisions still apply. As with all tracing, you trade completeness against cost. Decide deliberately.
So, is Jaeger for you?
If you have adopted OpenTelemetry for tracing and you want an open, standard place to store and explore those traces, Jaeger is a natural, well-supported choice, and v2 makes the OTel fit seamless. If you would rather not run a backend at all, a managed tracing service takes that on for you.
Where does your tracing chain break today? Usually it is one un-instrumented service. Reply, or book a slot and tell me what you found.
|
Get the next one One signal a week. No noise. | |
|
If this was useful, Metrics & Mayhem sends one short, practical piece like it to IT operations leaders most weeks. No fluff, no vendor noise.
Prefer to start with the book? Read a free chapter. |
Sources / further reading
Jaeger project: jaegertracing.io
Jaeger v2 released, OpenTelemetry in the core (CNCF): cncf.io
What database does Jaeger use, Cassandra vs Elasticsearch (SigNoz): signoz.io
Jaeger persistent storage with Elasticsearch, Cassandra, Kafka (CNCF): cncf.io