Tail-Based Sampling
Deciding whether to retain a trace after it completes, so that slow and failed traces are kept while routine successful ones are discarded.
Head-based sampling decides at the start — keep 1% at random. Cheap, stateless, and it discards 99% of the errors and slow requests, which are the only traces anyone looks at.
Tail-based sampling buffers spans until the trace completes, then decides: keep all errors, keep everything above a latency threshold, keep a small percentage of successes for baseline comparison.
This is what makes tracing affordable at high volume without losing its value. A 1% baseline plus 100% of errors and slow traces is typically a very small fraction of total volume and retains nearly all the diagnostic content.
The costs: the collector must buffer all spans for a trace, which requires memory and requires that all spans for one trace reach the same collector instance — so collectors must be load balanced by trace ID. That is a real operational constraint and the usual reason it is not enabled.
Related: sampling must be consistent across services. If each service samples independently, traces fragment. The sampling decision propagates in the trace context so the whole trace is retained or discarded together.