Workflow: distributed tracing across services

TL;DR

Use the same sampling strategy in every service, ideally via a shared traces\sampler. Every service gets tracing enabled, even services you think do not need it. A service with tracing unset breaks inbound trace continuation; a service at traces\sample\_rate=0 still continues incoming traces. Unset is the enemy, 0 is fine.

When to use

You are seeing this: One trace per request across every service is the goal. Use this skill when you run into "Workflow: distributed tracing across services".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

One trace per request across every service is the goal. It breaks at boundaries by default; this workflow hardens each one.

1. Enable tracing everywhere, even at low rates

Every service gets tracing enabled, even services you think do not need it. A service with tracing unset breaks inbound trace continuation; a service at traces_sample_rate=0 still continues incoming traces. Unset is the enemy, 0 is fine.

2. Propagate through the infrastructure

The sentry-trace and baggage headers carry the trace. Audit every proxy, gateway, and WAF between your services and allowlist both headers. Log headers at one boundary during rollout to prove they survive the hop.

3. Sample consistently

Use the same sampling strategy in every service, ideally via a shared traces_sampler. The sampling decision propagates downstream; inconsistent strategies produce orphan spans and partial traces. Decide once, configure everywhere.

4. Name transactions by route pattern

Parameterize IDs out of transaction names in every service (GET /accounts/[id], not GET /accounts/48291). High-cardinality names fragment traces, dashboards, and span quota simultaneously.

5. Cover manual clients

Auto-instrumentation propagates headers for supported HTTP clients. For hand-rolled clients, inject the propagation headers from the current span context manually. Audit for custom fetch wrappers and queue publishers; they are the usual gaps.

6. Roll out boundary by boundary

Start with frontend to backend, verify joined traces, then extend to the next hop. Each boundary gets its own verification before moving on; debugging three broken boundaries at once is miserable.

Verify

Follow one request through every service in the trace view: a single connected tree, no orphans, sampling decisions consistent. Then check span quota: full-fidelity tracing across a fleet is a budget decision, and the sampler is where it gets made.

Researched against live Sentry docs 2026-09-26. The Python setup page (docs.sentry.io/platforms/python/) documents distributed tracing from frontend to backend. The Python options page (docs.sentry.io/platforms/python/configuration/options/) documents tracessamplerate/traces_sampler and the 0-vs-None continuation semantics. The quotas page (docs.sentry.io/pricing/quotas/) documents spans as their own quota category.