We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Uber's architecture grew to thousands of services processing millions of trips per day. When a rider reported a failed ride request, the request had touched 20+ services. Finding the failure point by reading logs from each service was taking engineers hours.
Uber built Jaeger (named after the German word for hunter) to solve this. It's a distributed tracing system designed to handle massive scale. Uber was generating 4 billion spans per day at peak. Jaeger was open-sourced in 2017, accepted into the CNCF, and graduated in 2019 as a mature project.
Today, Jaeger is one of the two most popular open-source tracing backends (alongside Zipkin) and is a standard component in -native observability stacks.
Jaeger has five main components:
| Component | Role |
|---|---|
| Agent | Lightweight daemon on each host that receives spans from applications and batches them for the Collector. Often deployed as a sidecar in . |
| Collector | Receives spans from Agents, validates them, and writes to storage. Horizontally scalable. |
| Storage | Pluggable backend. Elasticsearch, Cassandra, (for buffering), or Badger (for testing). |
| Query Service | Serves the UI and API for searching and retrieving traces. |
| UI | Web interface for visualizing traces as waterfall charts, searching by service/operation/tags. |
Jaeger natively supports OpenTelemetry, you can send OTLP data directly to the Jaeger Collector without a separate agent. The modern recommendation is to instrument with OpenTelemetry SDKs and use Jaeger as the backend.
For storage at scale, Elasticsearch is the most common choice, it provides full-text search on span tags and good query performance. Cassandra is used when write is the primary concern.