Setting Up OpenTelemetry So Traces Actually Connect

List every place a request's trace context needs to survive a hop it might not survive automatically: HTTP calls between services usually propagate context fine with standard OpenTelemetry instrumentation, but a message published to a queue, a background job enqueued for later, or a call into a different runtime often drops it unless you explicitly inject the trace ID into the message and extract it on the other side. Go through your architecture diagram and mark every queue, cron job, and cross-runtime call as a place to verify, not assume, propagation works.

Auto-instrumentation for common frameworks and libraries, your web framework, your database driver, your HTTP client, gets you a usable baseline with minimal code changes and should be your starting point everywhere it's available. Manual spans are worth the extra work only around business logic that's actually hard to reason about from the automatic spans alone, a complex calculation, a multi-step workflow inside one function. Instrumenting everything manually from the start is a common overcorrection that produces more maintenance burden than insight.

Head-based sampling, deciding whether to keep a trace at the moment it starts, is simple but risks dropping exactly the slow or erroring traces you most want to see, since the decision happens before you know the outcome. Tail-based sampling, deciding after the trace completes, lets you keep every error and every slow trace while sampling down the high-volume, uninteresting, fast successful ones, but requires a collector that can buffer and evaluate complete traces before deciding, which is a heavier infrastructure lift. Most teams past early scale need tail-based sampling to keep tracing both useful and affordable.

A trace ID that also appears in your structured logs for the same request turns "here's a slow span" into "here's the slow span, and here's the exact log lines from that request, including the ones from a service that isn't even instrumented yet." This correlation is usually a small logging configuration change, injecting the active trace ID into your logger's context, but it's the step that makes tracing genuinely useful for debugging instead of just a pretty flame graph nobody references during an actual incident.

Attaching high-cardinality values, a full request body, a raw user ID, an unbounded free-text field, as span attributes on every request multiplies your tracing backend's storage and cost far faster than most teams expect, and it's the single most common reason a team turns tracing off a few months after turning it on. Set explicit conventions for what's allowed as a span attribute before instrumentation spreads across your codebase, and review new high-cardinality attributes in code review the same way you'd review a new database index.

An OpenTelemetry Collector sitting between your services and your tracing backend gives you a single place to apply sampling rules, redact sensitive attributes before they leave your infrastructure, and switch backends later without touching application code. Someone needs to own its configuration and its own uptime, since a collector that falls behind or crashes silently drops trace data with no obvious symptom beyond gaps that are easy to miss until you go looking for a specific trace that isn't there.

Once propagation, sampling, and correlation are all working together, the real test is whether an engineer debugging a slow request reaches for the trace first, instead of grepping through logs across five services by hand. If your team still defaults to log grepping during an incident months after rolling out tracing, that's a signal something in the setup, usually propagation gaps or missing log correlation, is quietly undermining the tool's usefulness even though the dashboards technically show data flowing.

Here is the whole worksheet as a checklist:

1. Map every boundary where trace context may not survive on its own, such as message queues and background jobs.
2. Start with auto-instrumentation, then add manual spans where the baseline misses what matters.
3. Choose a sampling strategy that keeps slow and erroring traces, using tail-based sampling or an error-aware override.
4. Put the trace ID in your structured logs so a slow span links to that request's log lines.
5. Keep high-cardinality values, such as raw user IDs or full request bodies, out of span attributes.
6. Decide who owns the Collector pipeline for sampling, redaction, and backend changes.