What is Jaeger and How Does it Implement Distributed Tracing?
Learn what Jaeger is, how it collects and visualizes distributed traces via OpenTelemetry, and how sampling works — interview answer.
Expected Interview Answer
Jaeger is an open-source, CNCF-graduated distributed tracing system that collects, stores, and visualizes traces from instrumented applications, letting engineers see the full path and timing of a request as it crosses multiple microservices.
Applications are instrumented with an OpenTelemetry SDK (Jaeger’s own client libraries are now deprecated in favor of OTel) that generates spans as a request flows through the code, attaching a shared trace ID and parent-child relationships between spans. Those spans are exported — often via an OpenTelemetry Collector — to the Jaeger backend, which consists of a collector that validates and writes spans to a storage backend like Elasticsearch, Cassandra, or an in-memory store for local testing, and a query service that the Jaeger UI calls to render traces. The Jaeger UI displays a trace as a waterfall/Gantt-style view: each span is a horizontal bar positioned by start time and sized by duration, nested under its parent span, so a slow downstream call is visually obvious as the widest bar. Jaeger also supports adaptive sampling, since tracing every single request at high volume is expensive; a common strategy traces 100% of errors and slow requests but only a small percentage of normal fast requests.
- Visualizes the exact end-to-end path and timing of a request across services
- Pinpoints which specific service or call introduced latency
- Adaptive sampling keeps overhead manageable at high request volume
- CNCF-graduated and OpenTelemetry-compatible, avoiding vendor lock-in
AI Mentor Explanation
Jaeger is like the match officials’ review room that takes every tagged touch of the ball — bowler, bat, fielder relay, keeper — and lays them out on a single timeline strip, showing exactly how long each touch took relative to the others. A slow relay throw shows up as a visibly longer segment on that timeline compared to the quick bowler-to-bat touch. Because reviewing every single ball in a five-day match would be excessive, officials focus full review on close run-out calls while sampling only a fraction of routine deliveries. The review room does not touch the ball itself; it only assembles what the tagged touches already reported.
Step-by-Step Explanation
Step 1
Instrument the service
Add an OpenTelemetry SDK that creates spans with a shared trace ID as requests flow through the code.
Step 2
Export spans
Spans are sent to a Jaeger Collector, often via an OpenTelemetry Collector as an intermediary.
Step 3
Store the trace data
The Collector validates and writes spans to a backend like Elasticsearch or Cassandra.
Step 4
Query and visualize
The Jaeger UI queries the storage backend and renders the trace as a waterfall/Gantt view.
What Interviewer Expects
- Understanding of Jaeger’s architecture: instrumentation, collector, storage, query/UI
- Awareness that Jaeger now favors OpenTelemetry SDKs over its own deprecated clients
- Knowledge of why sampling is needed at scale and common sampling strategies
- Ability to explain what the waterfall view actually shows
Common Mistakes
- Thinking Jaeger stores traces itself without a separate storage backend
- Not mentioning sampling as a way to control tracing overhead
- Confusing Jaeger with a metrics or logging tool rather than a tracing tool
- Forgetting that instrumentation is required before Jaeger can show anything
Best Answer (HR Friendly)
“Jaeger is the tool we use to actually see a request’s journey across our microservices — once our code is instrumented to report timing data, Jaeger collects it, stores it, and shows us a visual timeline of every hop the request took. If a request is slow, we can open Jaeger and see at a glance exactly which service in the chain was the bottleneck, instead of guessing.”
Code Example
docker run -d --name jaeger \
-p 16686:16686 \
-p 4317:4317 \
-p 4318:4318 \
jaegertracing/all-in-one:latest
# Jaeger UI is now available at http://localhost:16686
# OTLP gRPC receiver listens on 4317, HTTP on 4318Follow-up Questions
- How does Jaeger’s collector relate to an OpenTelemetry Collector in a modern setup?
- What sampling strategies would you use for a high-traffic production service?
- What storage backends does Jaeger support and how would you choose one?
- How would you read a Jaeger waterfall view to find the slowest hop?
MCQ Practice
1. What does the Jaeger UI’s waterfall view primarily show?
The Jaeger waterfall view lays out spans as bars by start time and duration, making the slowest hop in a trace visually obvious.
2. Why does Jaeger typically use sampling rather than tracing every request?
At high request volume, tracing everything is expensive; sampling strategies (e.g. trace all errors, sample a fraction of normal traffic) balance cost against visibility.
3. What component does the modern Jaeger recommend for instrumenting applications?
Jaeger has moved to recommend OpenTelemetry SDKs for instrumentation, since its own native client libraries are deprecated.
Flash Cards
What is Jaeger? — A CNCF-graduated open-source distributed tracing system for collecting, storing, and visualizing traces.
What instruments a service for Jaeger today? — An OpenTelemetry SDK, since Jaeger’s native client libraries are deprecated.
What does the Jaeger UI render? — A waterfall/Gantt view of spans, showing timing and parent-child relationships in a trace.
Why does Jaeger use sampling? — To control the cost/overhead of tracing every request at high traffic volume.