Introduction to Distributed Tracing with Zipkin
When a request touches ten services, tracing tells you exactly where the time went.
In a microservices system, a single user request might hop through an API gateway, three services, a cache, and a database. When it’s slow, which hop is to blame? Metrics say “the system is slow”; logs are scattered across services. Distributed tracing stitches the whole journey together — and Zipkin is a classic, lightweight tool for doing it.
🎯 Learning Objectives
- Understand the problem distributed tracing solves
- See how tracing complements metrics and logs
- Know what Zipkin is and its architecture
- Understand the idea of a trace following a request across services
The Microservices Debugging Problem
In a monolith, a slow request is one process — a profiler finds the bottleneck. In microservices, one request fans out across many services and machines:
Client ▶ Gateway ▶ Orders ▶ Payments ▶ Bank API
│
└─▶ Inventory ▶ Database
"Checkout is slow." ...but which of these hops caused it?Metrics tell you that latency is high. Logs from each service are hard to correlate. Tracing answers where the time went, by following one request end-to-end.
Tracing vs. Metrics vs. Logs
| Pillar | Question it answers | Granularity |
|---|---|---|
| Metrics | How much / how fast, overall? | Aggregated numbers |
| Logs | What happened in detail, here? | Per-event, per-service |
| Traces | Where did this request’s time go across services? | Per-request, cross-service |
They complement each other: metrics alert you, traces localize the problem, logs give the detail. This section focuses on traces.
💡 Traces are per-request stories
A metric is a number over time; a trace is the story of a single request as it travels through your system, timed at every step.
What is Zipkin?
Zipkin is an open-source distributed tracing system (originally from Twitter). It collects timing data from your services and lets you search and visualize traces to find latency problems.
Its architecture has four parts:
Instrumented services ──spans──▶ Collector ──▶ Storage ──▶ UI / API
(send timing data) (in-memory, (search &
Cassandra, visualize
Elasticsearch) traces)| Component | Role |
|---|---|
| Reporter (in your app) | Records timing and sends it to Zipkin |
| Collector | Receives and validates incoming span data |
| Storage | Stores traces (in-memory for demos; Elasticsearch/Cassandra for real use) |
| UI / API | Search traces and view the waterfall timeline |
A Trace, Visually
Zipkin shows a trace as a waterfall — each service’s work is a bar, positioned by when it happened and sized by how long it took:
Trace: GET /checkout (total 820ms)
gateway ├────────────────────────────────────┤ 820ms
orders ├──────────────────────────────┤ 640ms
payments ├────────────────────┤ 480ms ◀ the bottleneck
inventory ├───┤ 90msAt a glance you can see payments dominated the request. That’s the power of tracing: the slow hop is obvious.
🧪 Hands-on Lab
Read the Waterfall
Given this trace, which service should you investigate first, and why?
gateway ├──────────────────────────┤ 700ms
search ├──┤ 80ms
ranking ├──────────────────┤ 520ms🧠 Knowledge Check
What problem does distributed tracing primarily solve?
In Zipkin's architecture, what does the Collector do?
💼 Interview Preparation
When would tracing help you where metrics and logs fall short?
Summary
You understand why distributed tracing exists, how it complements metrics and logs, and Zipkin’s architecture and waterfall view. Next, we unpack the building blocks of a trace: spans, trace IDs, and how context propagates between services.