Trace

A trace is the record of one operation, assembled from spans. Each span is one timed step (the HTTP handler, an auth call, three database queries, a payment API hop) and carries the shared trace ID plus a pointer to its parent, and nesting them by parent is what rebuilds the shape. Draw the spans as nested bars on a shared clock and you get the picture everyone actually wants: where the 4 seconds went, which step was waiting on which, and what ran in parallel versus in sequence.

The operation is usually an inbound request, but nothing about a trace requires it to leave the process. A background job, a batch step, or a single service handling work end to end all produce perfectly good single-process traces. Making one trace span several processes or services is the extra thing distributed tracing does, by propagating trace context on every outbound call. The trace is the data model, the record itself; distributed tracing is the practice that keeps that record intact across a boundary.

Reach for a trace when the metric already told you something is slow or failing and you need to know where. Metrics say 'p95 checkout latency doubled', traces say 'the coupon service adds 600ms and gets called four times'. Once the work does leave the process, the stitching happens by propagating a traceparent header on every outbound call, which OpenTelemetry does for you once the auto-instrumentation is in place. Jaeger, Tempo, Honeycomb, and the commercial APM tools all render the same waterfall.

Gotcha: traces break quietly. One service that drops the traceparent header (a hand-rolled fetch wrapper, a queue hop, a background job) turns the rest of the journey into orphan traces that look like separate requests, and the gap never announces itself. The other trap is sampling: at 1 percent head sampling, the slow request you came to investigate was probably thrown away, so use tail sampling to keep the errors and the slow ones.