observabilityestablished · medium operational burden

Distributed Tracing

Also known as: tracing, opentelemetry, jaeger, zipkin

Intent

Track request flow across service boundaries to understand latency, errors, and dependencies.

Problem

A request touches 10 services. Logs are fragmented. Finding the slow service or error root cause takes hours.

Forces

•Request spans multiple services, queues, databases
•Need end-to-end latency breakdown
•Error context lost at service boundaries
•Sampling required at scale (can't trace 100%)

Solution

✓ When to Use

•Any distributed system (>3 services)
•Latency debugging across service boundaries
•Error root cause analysis
•SLO/SLI measurement (latency percentiles)

✗ When Not to Use

•Monolith or 2-service system (logs sufficient)
•Ultra-high throughput where sampling loses signal
•Team not ready to instrument code

Pros

+End-to-end visibility
+Latency breakdown by service, DB, queue
+Error context with full call chain
+Enables tail-based sampling (keep errors, sample successes)

Cons

−Instrumentation effort (auto helps but not complete)
−Storage cost at scale (sampling required)
−Context propagation breaks if middleware misses headers
−Clock skew distorts timings

Cost Profile

Infrastructure

Medium — collector, storage, query backend

Operational

Medium — sampling config, retention, cardinality

Cognitive

Low — intuitive concept, standard APIs

Failure Modes

Broken context propagation → fragmented traces
High cardinality attributes → storage explosion
Sampling misses rare errors (tail-based mitigates)
Clock skew → negative durations, wrong ordering

Real-World Examples

Alternatives

structured-logging
metrics-only
correlation-ids

Related Patterns

structured-logging
metrics
correlation-id
service-mesh

Competency Domains

reliability opsdistribution communicationeconomics evolution