Distributed tracing helps monitor microservices by following an individual request as it travels across multiple services, giving end-to-end visibility that isolated per-service logs and metrics can't provide on their own.
Key Points: • It shows the complete path a request takes across services, including how much time was spent in each one. • It pinpoints exactly where delays occur, making it far faster to identify a slow service in a chain than manually correlating timestamps across separate logs. • It reveals dependency relationships between services, showing how a change or slowdown in one service impacts others downstream. • Tools like Zipkin and Jaeger visualize traces as timelines (often called flame graphs or waterfall views), making the request flow easy to interpret visually. • Combined with metrics and logs, tracing completes the "three pillars of observability," giving both the big picture and the detail needed to fix a specific issue.
Example: If users report a slow checkout, a trace covering the request from the API Gateway through the Order, Inventory, and Payment services can immediately show that 90% of the total time was spent waiting on the Payment service, directing debugging effort to the right place instead of guessing.
Interview Tip: A concise interview answer is:
"Distributed tracing follows a single request across every service it touches, showing exactly where time was spent and which service is responsible for a slowdown or failure. Without it, you're stuck manually correlating logs across a dozen services; with tools like Zipkin or Jaeger, that same investigation takes seconds instead of hours."