The "Where Did It Go?" Problem
In a monolithic application, if a request is slow, you look at the logs of that one server. The entire execution path lives in one process, on one machine. Debugging is tedious, but at least everything is in one place.
In a microservices architecture, a single user click might trigger a chain reaction involving 20 different services, five databases, and three message queues. If that click is slow, or it fails, where is the bottleneck? Is it Service A? Service G? The network between D and E? Did Service K call Service M three times when it should have called it once?
Logs alone can't easily answer these questions. You'd have to manually stitch together timestamps from 20 different log streams, correlate them by hand, and hope that every service's clock is synchronized to the millisecond. This is not a scalable debugging strategy.
Enter Distributed Tracing
Distributed Tracing is the technology that reconstructs the entire journey of a single request as it propagates through a distributed system. It gives you a single, unified view of what happened, in what order, and how long each step took.
Think of it like a package tracking system for your data. When a request enters your system, it gets a unique tracking ID. Every service that handles the request "scans" it, recording when it arrived and when it left. Tracing is the system that collects all those scans and builds a timeline view of the request's journey — so you can see at a glance that Service K is the culprit, and it's spending 800ms waiting on a slow database query.
Without distributed tracing, debugging a latency spike in a microservices system is like trying to reconstruct a relay race from 20 separate stopwatches held by 20 different people who don't talk to each other.