DevOps
Tracing
Distributed tracing follows a single request across every service it touches, timing each hop so you can pinpoint where latency or errors actually originate in a microservice call graph. Tools like OpenTelemetry and Jaeger propagate a trace ID end to end. It is the piece of observability that logs and metrics alone cannot give you.
Purpose
Distributed tracing follows one request across every service it touches, recording each hop as a timed span in a tree. When a page takes three seconds, the trace shows exactly which of the seven services — and which query inside it — spent the time.
When to Use It
Latency debugging in microservice systems (the flame-graph view of a slow request), error attribution across service boundaries, and dependency mapping — discovering what actually calls what in a system too big to hold in one head.
Trade-offs
Tracing every request at full detail is expensive, so production systems sample — keeping the interesting traces (slow, failed) is the art. Instrumentation must propagate context through every hop and queue; one non-participating service cuts the trace in half.
Implementation
Standardise on OpenTelemetry: auto-instrument frameworks and HTTP clients, propagate the W3C traceparent header, and export spans to a backend (Jaeger, Tempo, or a vendor). Attach the trace ID to logs so the two datasets join, and set sampling to keep errors and outliers.