Key details

  1. Honeycomb announced the donation on September 1, 2026.
  2. The processor is based on techniques from Honeycomb’s open-source Refinery tail-sampling proxy.
  3. Supported concepts include trace fingerprinting, adaptive percentage targets, adaptive throughput targets, static rules and sample-rate attribution.
  4. Honeycomb says adaptive rates recalculate as traffic changes rather than remaining fixed.
  5. The Honeycomb Collector Distribution bundles the processor today.
  6. The upstream OpenTelemetry component is still working toward alpha.

What builders should take away

  1. If telemetry cost is currently controlled with a blanket percentage, test a fingerprint-based policy on representative traffic and compare rare-route coverage before changing production retention.
  2. Define fingerprints around dimensions that represent genuinely different journeys—such as tenant, route and service path—rather than high-cardinality attributes that would fragment the sampling budget.
  3. Keep deterministic rules for errors or other must-retain traces ahead of adaptive policies.
  4. Pin the Honeycomb Collector distribution to a release rather than `latest` for production experiments, and track the upstream OpenTelemetry status before standardizing configuration across environments.
  5. Verify how the destination backend handles OpenTelemetry sample-rate attribution before relying on extrapolated counts.

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.

Timeline

2026-09-01

Honeycomb announces OpenTelemetry donation

Honeycomb publishes the adaptive tail-sampling processor design and a usable build in its Collector distribution.
2026-09-04

Upstream work remains pre-alpha

Honeycomb’s published guidance still describes the processor as working toward alpha in the upstream OpenTelemetry Collector.

What to watch next

  • When the adaptive tail-sampling processor reaches alpha, beta and stable status upstream.
  • Whether official OpenTelemetry Collector distributions converge on the same configuration schema as Honeycomb’s current implementation.
  • How other observability backends consume and expose OpenTelemetry sampling-threshold attribution.

Still unclear

  • The upstream OpenTelemetry contribution has not yet reached alpha, so configuration and behaviour may change before it becomes a standard Collector component.
  • Honeycomb is the author of the announcement and the current implementation evidence; broader independent production experience is not yet available for the upstream component.

Sources

Direct reading behind this dossier.

1 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment