Head-based sampling is the simplest and most widely deployed sampling strategy. It makes its decision at the very start of a request — before any work is done — which is both its greatest strength and its fundamental limitation.
How It Works
When the first service in a call chain receives a request with no existing trace context (meaning it's a new trace), it must decide: sample or not?
Probabilistic head sampling works like a weighted coin flip:
if random() < sampling_rate:
mark trace as sampled
else:
mark trace as not sampled
A 10% sampling rate means roughly 1 in 10 traces is kept. The decision is made in microseconds, before the first downstream call is made.
The Mechanics in OpenTelemetry
In the OpenTelemetry SDK, head sampling is configured via a Sampler. The built-in TraceIdRatioBased sampler uses the TraceID itself (a random 128-bit number) to make a deterministic, consistent decision — instantiated with a single ratio argument (e.g. 0.10 to keep 10% of traces).
Because the decision is based on the TraceID (which is fixed for the lifetime of the trace), every service that evaluates the same TraceID with the same ratio will reach the same decision — providing a form of coherency even without explicit flag propagation.
Trade-offs
| Property | Head-Based Sampling |
|---|---|
| CPU overhead | Minimal — decision made once at trace start |
| Memory overhead | None — dropped traces never enter memory |
| Captures all errors | ❌ No — errors are sampled at the same rate as successes |
| Implementation complexity | Low |
| Suitable for | High-volume, low-criticality services; baseline traffic sampling |
The fundamental flaw: Head sampling is blind to outcomes. At the moment of decision, the request hasn't executed yet. You don't know if it will fail, be slow, or trigger a rare code path. A 10% head sample captures 10% of your errors — which means if errors occur at a rate of 1 in 10,000 requests, you'll statistically miss 90% of them.
Key Point: Head sampling is appropriate when your error rate is high enough that a random sample will still capture statistically meaningful numbers of errors, or when you're sampling for performance profiling rather than error debugging. For billing systems, payment processors, or any service where missing a single error trace is unacceptable, head sampling alone is insufficient.