# What is Distributed Tracing?

> Distributed tracing tracks a single request as it travels through the services of a distributed system, recording timing and context at every hop so you can pinpoint where latency and errors originate.

Source: https://openobserve.ai/glossary/what-is-distributed-tracing/
Published: 2026-07-08
Term: Distributed Tracing
Category: Tracing & APM
Related terms: what-is-a-span, what-is-apm, what-is-otlp, three-pillars-of-observability

---

**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](/glossary/what-is-a-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](/blog/how-to-auto-instrument-distributed-services/) 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](/glossary/what-is-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](/glossary/three-pillars-of-observability/)

## Distributed tracing in OpenObserve

OpenObserve's [tracing](/traces/) 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](/blog/distributed-tracing-basics-to-beyond-guide/).