Distributed tracing tracks a request as it moves through multiple services, collecting timing, metadata, and error context into a connected trace for debugging latency and failures.
Distributed tracing assigns a unique trace ID to each request. Each service or hop creates a span with timing, status, and metadata. A trace is the tree of spans that represents the full request path across databases, APIs, queues, and downstream services.
That cross-service view is what makes distributed tracing indispensable in microservice architectures. Logs and metrics show that something is wrong; traces show where time is spent and which dependency caused the slowdown. Without trace context, debugging a slow checkout flow across five services requires manual correlation and guesswork.
Think of it like this. Think of a parcel tracking number that shows every sorting facility, truck, and handoff instead of only 'delivered' or 'failed'.
An instrumentation layer injects trace context into requests using headers or propagation libraries. Each instrumented service creates spans for its work and exports them to a backend. Backends join spans by trace ID, render timelines, and identify slow paths, retries, and failed dependencies.
"Tracing is just logging with IDs." Traces must include timing, parent-child relationships, and system boundaries to be useful. "Tracing everything is the goal." Sampling and cardinality control are necessary to keep cost and overhead low. "One vendor format is enough." Interoperability standards improve portability and reduce lock-in.
Uncovers latency and coupling patterns invisible in logs, but instrumentation overhead, sampling strategy, and storage cost require active management. Best paired with metrics and logs for full observability.