Why is trace sampling dropping important requests

Trace sampling can make important requests “disappear” because it’s designed to record only a subset of traffic, not everything. Common reasons include:

• Sampling rate is too low
  If you sample 1% of traces, 99% won’t be recorded—even if some of those are the important ones.

• Sampling happens before the system knows a request is important
  Many samplers decide at the start of a request, before they know whether it will be slow, error-prone, or business-critical.

• Random sampling misses rare events
  Important requests are often rare: edge cases, intermittent failures, specific customer paths, or unusual latency spikes.

• Head-based sampling ignores later context
  With head-based sampling, the decision is made at trace start. If the request becomes problematic later, it may already have been dropped.

• Unsampled traces can’t be promoted later
  If you never collected the trace, you can’t inspect it afterward unless you also have logs/metrics or another signal.

• Load or budget constraints force aggressive sampling
  Teams lower sampling to control storage/cost, which can unintentionally filter out the exact traces needed for debugging.

How to avoid missing important requests

• Use tail-based sampling so you can keep traces based on status, latency, or errors after the request finishes.
• Add rule-based sampling for critical endpoints, premium customers, or error responses.
• Keep 100% sampling for errors or slow requests when possible.
• Correlate traces with logs and metrics so you can still find what was dropped.
• Review whether sampling is applied at the edge, service, or collector, since each affects what gets lost.

If you want, I can also explain the difference between head-based vs tail-based sampling and which one is better for important requests.