Distributed Tracing & Centralized Logging
One request that touches five services produces five separate sets of logs, on five separate machines. This module is how to make that feel like ONE trace again.
Learning objectives
- Beginner: Explain what a trace ID is and why it needs to survive a call from one service to another.
- Intermediate: View a distributed trace across multiple services in Zipkin.
- Advanced: Correlate a slow trace span back to the specific log lines it produced, across two different services.
◆ The problem
Spring Boot Mastery's Logging module covered a correlation ID surviving across log lines WITHIN one service. Once a request crosses into order-service, then inventory-service, then payment-service, that ID needs to survive across a NETWORK CALL, propagated in an HTTP header from each service to the next — otherwise each service's logs are an island, and reconstructing the full path a request took means manually cross-referencing timestamps across three unrelated log files.
Distributed tracing (via Micrometer Tracing, the successor to the older Spring Cloud Sleuth) automatically generates a trace ID at the first service a request hits, and propagates it through every downstream call automatically — including through Feign and WebClient calls covered earlier in this category, with zero code changes needed in the calling code itself.
A single distributed trace is made of multiple SPANS — one span per service (or even per significant operation within a service) that the request touched, each recording its own start time, duration, and the trace ID tying it back to the overall request.
| Concept | What it represents |
|---|---|
| Trace | The entire end-to-end journey of one request across every service it touched. |
| Span | One unit of work within that journey (one service's handling of it, or one significant sub-operation). |
| Trace ID | Shared by every span in the same trace — the thread tying them all together. |
Micrometer Tracing exports spans to Zipkin (or an OTLP-compatible backend like Jaeger), which renders the full trace as a timeline — visually showing exactly how long each service spent handling its piece, and instantly revealing which ONE service in a 5-service chain is actually responsible for a slow overall request, rather than guessing from scattered logs.
◆ Under the hood
This is the same distributed-tracing concept the Kafka & Microservices category's Health, Monitoring & Observability module and the Spring AI category's Observability module both reference — it's one unified concept applied consistently across every part of this course, not three separate tools to learn.
Tracing shows WHERE time went; centralized logging (shipping every service's structured JSON logs, from Spring Boot Mastery's Logging module, into one searchable system like Loki or the ELK stack) shows WHAT actually happened at each step. With the trace ID present in both, you can jump from a suspicious slow span directly to the exact log lines that span produced, across a completely different service, in one search.
✓ Quick recap
- A trace ID must propagate across network calls, not just log lines within one service — tracing libraries do this automatically through Feign/WebClient.
- A trace is made of spans — one per service (or operation) the request touched, each with its own duration.
- Zipkin/Jaeger visualize the full trace as a timeline, instantly showing which service actually caused a slow request.
- Centralized logging plus a shared trace ID lets you jump from a slow span straight to the log lines it produced, even in a different service.
Want a visual for this concept?
Generate a diagram tailored to “Distributed Tracing & Centralized Logging” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →