What changed
On September 1, Honeycomb announced that it is donating an adaptive tail-sampling processor to the OpenTelemetry Collector. The component brings techniques developed around Honeycomb’s open-source Refinery proxy into Collector pipelines: trace fingerprinting, dynamically adjusted sample rates, percentage or throughput targets, static keep/drop rules and sample-rate attribution. Honeycomb’s Collector distribution already bundles the processor, while Honeycomb says the upstream OpenTelemetry contribution is still working toward alpha.
Why it matters
Sampling is one of the main levers teams use to control telemetry volume and observability cost, but static or purely random policies can discard rare journeys while over-representing high-volume traffic. Adaptive sampling changes that trade-off by grouping traces into meaningful fingerprints and allocating the sampling budget across those groups. If the processor reaches standard OpenTelemetry distributions, teams could gain a more portable cost-control primitive without inserting a separate vendor-specific sampling service into the telemetry path.
The sampler changes rates instead of applying one fixed percentage
The processor can identify traces by attributes such as service names, HTTP routes, tenant IDs or status codes. It then adjusts the sample rate per fingerprint rather than treating every trace as equivalent, preserving more low-volume paths while sampling high-volume paths more aggressively.
Teams can target percentage or absolute throughput
Honeycomb documents two adaptive goals. `adaptive_percentage` aims to keep a chosen share of overall traffic, while `adaptive_throughput` aims for an approximate spans-per-second budget. Rates are recalculated on a configurable interval so a traffic spike does not automatically produce the same multiple of telemetry volume.
Important traces can still bypass the adaptive budget
Static rules run alongside adaptive rules. A pipeline can keep all traces containing errors or slow requests before applying adaptive sampling to the remaining traffic, which lets teams reserve full fidelity for known high-value cases.
Sample-rate attribution is part of the design
The processor emits OpenTelemetry sampling-threshold information through `tracestate`, allowing compatible backends to understand what each sampled trace represents and make more accurate extrapolations from sampled data.
Upstream OpenTelemetry status is not production-ready yet
Honeycomb’s own Collector distribution includes the component today, but the company says the upstream contribution is still moving toward alpha. Builders should treat the current Honeycomb distribution as the practical test path and avoid assuming the processor is already present or stable in official OpenTelemetry Collector images.