Metrics proved Saturday checkout is slow; logs named the error but not where the time goes. What neither can say is where the time goes inside one request crossing five services — and that question is the third signal's whole job. This chapter builds tracing end to end: spans and context propagation, OpenTelemetry instrumentation, the Collector pipeline, a sampling policy that keeps every error, and Tempo with full three-signal correlation — and it ends by answering the question Chapter 1 opened.
6 topics
A 9-second checkout touches web, bookings, db-01, cache-01, and payments before the customer sees anything. The Chapter 5 histogram says the p99 breached; the Chapter 7 logs name a connection pool timeout without saying where the wait happened. Neither can say which hop inside that one request ate the budget, because metrics aggregate away the individual request and logs cannot tie five services' lines to the same one. A trace — one request rendered as a timed tree — answers by construction what the other signals structurally cannot.
Six topics build the signal: why tracing exists and what it alone answers; spans, traceparent, and the three places propagation breaks; OpenTelemetry's API-SDK-OTLP seam that instruments once for any backend; the Collector pipeline that carries all three signals through one process; sampling policy that keeps every error and slow trace while dropping the boring 99%; and Tempo with exemplar-driven correlation — where the Saturday mystery, seven chapters old, finally gets its answer.
One checkout as a trace waterfall — spans left to right in start-time order, not call order