Skip to content
Devgo

Distributed tracing

Following a single request across service boundaries via spans, showing where time is spent and where errors occur. Essential for microservice debugging. Usually sampled to control cost. OpenTelemetry is the standard.

When to use
  • Microservice latency/error debugging.
  • Understanding request paths.
When not to
  • Monoliths (less cross-service value).
  • When cost of full tracing is unjustified.

Definition

A trace is a tree of spans, each a unit of work in a service, linked by trace/context IDs propagated across calls. It reconstructs a request's path and timing through the system, pinpointing slow or failing hops.

Why it exists

In microservices, a slow request could be any hop. show aggregate latency; traces show the specific path and span causing it, across service boundaries.

How it works

Inject/extract trace context (W3C traceparent) on every call. Each service creates spans. Collectors ship spans to a backend (Tempo, Jaeger). (head/tail) controls volume; tail sampling keeps interesting traces.

Scaling limits

Tracing every request is too expensive ( needed). Context propagation must be in every hop or traces break. High cardinality of trace IDs needs a tracing backend, not a TSDB.

Cost shape

Ingestion + storage of spans; controls it. Blow-ups: 100% sampling and long retention.

Alternatives

  • Logs with correlation IDs — Cheaper but manual to reconstruct flow.
  • Metrics — Aggregate only, no per-request path.

Failure modes

  • Broken context propagation splitting traces.
  • dropping the interesting trace.
  • Backend query cost.

, , , ,