How Adaptive Tail Sampling Works in the OpenTelemetry Collector

Honeycomb’s adaptive_tail_sampling processor brings adaptive trace sampling algorithms from Refinery and dynsampler-go to the OpenTelemetry Collector, aiming to retain important traces such as errors and rare routes while preserving statistically accurate traffic estimates. Unlike fixed head sampling, it buffers traces until completion signals or limits are reached, applies ordered OTTL-based rules, and records each decision as a W3C TraceState sampling threshold so downstream tools can reweight sampled data correctly. It supports adaptive percentage sampling for a target share of traffic, adaptive throughput sampling for a span-volume budget, and fixed or always-keep rules, with fingerprints such as service name and HTTP route used to distinguish traffic classes. The processor handles late spans through a decision cache, makes rule-based decisions during buffer evictions, drains buffered traces on shutdown, and can compose with existing OpenTelemetry samplers so the strictest effective probability is retained. Benchmarking indicated high throughput and bounded memory under overload, though deployments require routing all spans for a trace to the same Collector instance, rules require restarts to change, and memory limits are based on trace and span counts rather than bytes. Available in beta in Honeycomb’s Collector distribution and progressing upstream, the processor offers Collector-native adaptive sampling, while Refinery remains positioned for more mature operational requirements such as clustered scaling, live rule changes, overload protection, and multi-tenant operations.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.