Jaeger Tracing
By Uber (open-sourced under CNCF)
Jaeger is an open-source, end-to-end distributed tracing system originally built at Uber to help engineers understand how a single request flows through a microservices architecture. It captures timing and metadata for each step a request…
Definition
Jaeger is an open-source, end-to-end distributed tracing system originally built at Uber to help engineers understand how a single request flows through a microservices architecture. It captures timing and metadata for each step a request takes across services, then assembles those steps into a trace that shows latency, dependencies, and errors along the request's full path. Jaeger is now a CNCF graduated project and one of the most widely deployed tracing backends alongside instrumentation standards like OpenTelemetry.
Overview
As applications split into dozens or hundreds of microservices, a single user request can hop across many independently deployed services, making it difficult to answer basic questions like which service is slow or where an error originated. Jaeger addresses this by collecting spans, timed units of work tagged with service and operation names, from every service a request touches, and stitching them together into one trace that visualizes the full call graph. Mechanically, applications are instrumented to emit spans carrying a shared trace identifier that propagates through request headers as the call moves between services. Jaeger's agent or collector receives these spans, and a storage backend, commonly Elasticsearch, Cassandra, or a scalable time-series-friendly store, persists them for later querying. Jaeger's UI then reconstructs the trace as a timeline, showing which service handled each span, how long it took, and where parallel calls overlapped, letting an engineer pinpoint the exact hop that added latency or threw an error. Jaeger sits in the tracing pillar of observability, distinct from metrics systems like Prometheus and log aggregation tools; it answers "where did time go for this specific request" rather than "what is the aggregate error rate." Historically Jaeger competed with Zipkin, an earlier tracing system with a similar model, and with proprietary APM tracing features from vendors like Datadog or New Relic. The rise of OpenTelemetry as a vendor-neutral instrumentation standard has shifted Jaeger's role somewhat, since teams often instrument with OpenTelemetry and choose Jaeger as one of several possible backends to receive that data. In practice, teams deploy Jaeger's collector and query service in their cluster, instrument application code with OpenTelemetry or Jaeger's own client libraries, and use the UI to debug slow requests, understand service dependencies, or investigate cascading failures during incidents. Sampling is typically applied so that only a fraction of requests are fully traced, since capturing every request at scale would be storage- and cost-prohibitive. The main limitations are around storage cost and sampling trade-offs: full tracing of every request is rarely practical at high volume, so engineers work with samples that may miss the specific slow request they are investigating. Jaeger also only shows what was instrumented, so gaps in instrumentation coverage produce broken or incomplete traces. Teams needing tightly integrated tracing, metrics, and logs correlation sometimes prefer a commercial APM suite over assembling Jaeger with separate metrics and logging tools themselves, since operating Jaeger's collector, storage backend, and UI as separate infrastructure adds ongoing maintenance work that a managed vendor product absorbs on the customer's behalf.
Key Features
- Reconstructs full request traces across many microservices
- Captures per-span timing, tags, and error information
- Pluggable storage backends including Elasticsearch and Cassandra
- Interactive UI for visualizing trace timelines and dependencies
- Supports adaptive sampling to control tracing volume and cost
- CNCF graduated project with broad ecosystem integration
- Compatible with OpenTelemetry instrumentation as a trace backend