Jaeger: CNCF Distributed Tracing Platform

What Jaeger is

Jaeger is a distributed tracing platform. In a system made of many services, a single user request can pass through dozens of processes, and logs or per-service metrics rarely show where the time went. Tracing records each hop as a span and stitches the spans into a trace, so you can see the full request path, its latency breakdown and the errors along the way. Jaeger provides the backend that receives, stores and queries those traces, plus a web UI for exploring them.

The project was created at Uber Technologies and donated to the Cloud Native Computing Foundation. The README notes that it became the CNCF's 7th top-level project and graduated in October 2019. The current major version, Jaeger v2, is rebuilt on top of the OpenTelemetry Collector, and the project recommends instrumenting applications with OpenTelemetry SDKs, which send data to Jaeger over the OpenTelemetry Protocol (OTLP).

Jaeger is aimed at platform, SRE and backend teams running microservices who want a self-hosted tracing backend with open governance, rather than a commercial observability suite.

How Jaeger works

The README's architecture diagram shows the data path: an OpenTelemetry SDK inside the application sends spans over HTTP or gRPC to the Jaeger Collector, which writes them to storage directly or through a gRPC storage plugin. The Jaeger Query service reads from the same storage and serves the Jaeger UI. The collector also serves sampling configuration back to the SDKs over gRPC.

In v2, all of this ships as a single binary that can take different roles, according to the architecture docs:

• collector: receives trace data and writes it to a storage backend.
• query: serves the query APIs and the UI.
• ingester: reads spans from Kafka and writes them to storage, for a collector, Kafka and ingester pipeline.
• all-in-one: collector and query in one process.
• agent: possible, but the docs recommend the standard OpenTelemetry Collector for this role instead.

Because the binary is a customised OpenTelemetry Collector distribution, it bundles upstream receivers (OTLP, Jaeger, Kafka, Zipkin), processors (batch, tail sampling, memory limiter, attributes, filter), exporters and connectors such as span metrics, alongside Jaeger's own storage extension, storage exporter, query extension and sampling components. You can build a custom distribution with more or fewer components using the OpenTelemetry Collector Builder.

The docs describe two common scalable layouts. In direct to storage, collectors write straight to the database, which must absorb peak traffic; a sustained spike can drop data. In via Kafka, collectors export to Kafka as a persistent buffer and one or more ingesters write to storage, partitioning the load among themselves.

Key features

• OTLP ingestion: accepts the OpenTelemetry Protocol on gRPC port 4317 and HTTP port 4318.
• Multiple storage backends: Cassandra, Elasticsearch and OpenSearch are the primary distributed backends; ClickHouse is supported as an experimental backend behind a feature gate; Badger provides embedded storage and an in-memory store covers testing.
• Remote Storage API: a gRPC API for custom backends run as a separate server; the docs list a community PostgreSQL implementation.
• Archive storage: a second backend with longer retention for traces you explicitly save, for example ones linked to an incident.
• Sampling: head-based sampling with central remote configuration, static or adaptive, plus tail-based sampling through the OpenTelemetry tail sampling processor.
• Service Performance Monitoring: aggregates metrics from traces and charts service performance trends as time series.
• Topology graphs: a system architecture graph of one-hop service dependencies and a deep dependency graph centred on a chosen service.
• Large-trace UI: the React UI is optimised for big traces; the docs mention testing a trace with 80,000 spans.
• Zipkin compatibility: accepts Zipkin Thrift, JSON v1 and v2 and Protobuf over HTTP, so existing Zipkin instrumentation can be pointed at Jaeger.
• Self-observability: backend components expose Prometheus metrics and write structured logs to stdout.

Getting started with Jaeger

The README starts Jaeger's all-in-one configuration, which includes the UI, collector, query service and in-memory storage, in one container:

docker run --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  jaegertracing/jaeger:latest

The UI is then available at http://localhost:16686, and applications send traces via OTLP on 4317 (gRPC) or 4318 (HTTP). Other roles need an explicit YAML configuration file passed with --config. Applications must be instrumented first; the docs recommend OpenTelemetry SDKs.

To see realistic traces without instrumenting your own code, the getting-started guide recommends the HotROD demo, a small ride-sharing application made of several microservices:

git clone https://github.com/jaegertracing/jaeger.git jaeger
cd jaeger/examples/hotrod
docker compose up

The demo UI runs on http://localhost:8080. The guide also asks you to export a JAEGER_VERSION variable with the newest release before starting it. For Kubernetes, the features page points to a Jaeger operator and a Helm chart.

Use cases

• Latency investigation: find which service or call dominates a slow request and whether calls that could run concurrently are running serially.
• Error tracing: follow a failing request across service boundaries and see where the error started.
• Dependency discovery: generate a data-driven service map of what actually calls what.
• Migrating off Zipkin: keep existing Zipkin-instrumented services while moving to an OpenTelemetry-based backend.
• Trace-derived service metrics: use SPM to compute aggregate metrics from traces and chart service performance trends over time.

How Jaeger compares

Jaeger sits alongside other open-source tracing backends such as Zipkin, which it is wire-compatible with, and Grafana Tempo, as well as commercial APM products. Its distinguishing points, as described in its own docs, are CNCF governance, a v2 architecture that is literally an OpenTelemetry Collector distribution, and a choice of mature storage backends rather than a single bundled store. If you already run OpenTelemetry Collectors for metrics and logs, the docs say you can keep them in front of Jaeger as sidecars, host agents or a remote cluster; Jaeger itself does not require them.

Trace storage is the part to plan for: Jaeger relies on an external database for production use, and the storage docs say the Jaeger team recommends OpenSearch over Cassandra for large-scale production deployments.

Things to know before adopting Jaeger

• License: Apache-2.0.
• In-memory is for testing: all-in-one with in-memory storage loses data on restart. Badger works in production only for modest volumes, since it is limited to a single instance.
• Supported storage versions: as of July 2026 the README's policy covers Elasticsearch 9.x and 8.19.x, OpenSearch 3.x and 2.19.x, Cassandra 5.0.x and maintained 4.x lines, and ClickHouse 26.3 and 25.8 LTS. Older versions may still work but are not covered.
• Deprecation policy: deprecated configuration options get a grace period of at least three months or two minor releases, whichever is later.
• Configuration: v2 behaviour is customised through a YAML configuration file, and running any role other than all-in-one requires one.
• Internal data model: Jaeger ingests OTLP, but the features page notes that the internal representation and UI still follow the OpenTracing model.
• Security audits: third-party audit reports are published in a separate repository.

Project activity

As of October 2026 the repository has about 23,300 stars. It was created in April 2016, is written in Go and is licensed under Apache-2.0, with commits landing in October 2026; the documentation covers releases up to v2.22. The UI and data model live in separate repositories, and adopters are listed in ADOPTERS.md. The source is at github.com/jaegertracing/jaeger and the documentation is at jaegertracing.io/docs.