What is Distributed Tracing?

Distributed tracing is the technique of following a single request end-to-end as it flows through a distributed system — every service, queue, and database it touches — and recording a timed span for each operation. The result, a trace, is a tree showing exactly where time was spent and where failures occurred.

The problem it solves

In a microservices architecture, one user action can fan out into dozens of internal calls. When that action is slow, per-service logs and metrics can each look healthy — the latency hides in the gaps between services, in retries, or in one slow query three layers deep. Tracing reconstructs the whole causal chain, turning “checkout is slow” into “the inventory service’s database query added 800ms.”

How it works

1. Instrumentation — each service’s tracing library (typically OpenTelemetry) starts and ends spans around meaningful operations; auto-instrumentation covers common frameworks without code changes
2. Context propagation — the trace ID travels with the request in headers (W3C Trace Context), so every service parents its spans correctly
3. Export — spans stream to a backend via OTLP
4. Reassembly & analysis — the backend stitches spans into traces and renders waterfall/flame views, service maps, and latency analytics

What traces give you

• Latency attribution — which hop, query, or external call is responsible for p99
• Error localization — the exact span where a failure started, with its context
• Dependency mapping — an always-current picture of what calls what
• Cross-signal pivots — trace IDs in logs connect the story across the three pillars

Distributed tracing in OpenObserve

OpenObserve’s tracing ingests OTLP natively, links traces with logs and metrics by trace ID, and stores spans on object storage — making it economical to retain traces at volumes where per-GB-priced tools force aggressive sampling. Start with the basics-to-beyond guide.