Distributed tracing records the path of one request as it passes through many services. Each unit of work is a span with a start time, duration and metadata, and the spans of one request share a trace ID so they can be assembled into a tree.
Why it matters
In a microservice architecture a single page view may touch a dozen services, databases and third-party APIs. Metrics show that the whole request is slow, and logs from each service are scattered. A trace shows exactly which hop consumed the time, which calls ran in sequence instead of parallel, and where an error originated. A trace is the third classic telemetry signal alongside metrics and logs.
Example
A trace for GET /checkout taking 1,900 ms might look like:
checkout-api 1900 ms
cart-service 120 ms
inventory-service 240 ms
payment-gateway 1450 ms <- slow span
The slow span points to the payment call. Context travels between services in a header, such as the W3C traceparent header.
Common mistakes
- Failing to propagate the trace header through one service, which splits the trace in two.
- Sampling too aggressively and missing rare slow requests. Consider keeping all errors and slow traces.
- Leaving out database and outbound HTTP calls from instrumentation.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.