For two years the Helix native agent had features OpenTelemetry couldn't match. That gap is closed, and it changes what we recommend to new customers.

We built a native agent early on because OpenTelemetry, in its early state, simply couldn't do tail-based sampling or continuous profiling well. That was a real technical gap, not vendor lock-in for its own sake, but it meant OTel-native shops had to choose between their existing instrumentation investment and our best features. That trade-off is gone.

What was actually missing in OTel

The OpenTelemetry Collector's tail-sampling processor existed but couldn't buffer per-service windows independently, and there was no standard signal type for profiles until the profiling data model stabilized last year. We spent two quarters contributing to and adopting that spec rather than inventing a competing one.

Configuring the OTel Collector for full parity

exporters:
  otlphttp/helix:
    endpoint: https://ingest.helix.dev
    headers:
      x-helix-api-key: ${HELIX_API_KEY}
processors:
  tail_sampling:
    policies:
      - name: errors-and-slow
        type: and
        and:
          sub_policy:
            - type: status_code
              status_code: { status_codes: [ERROR] }
service:
  pipelines:
    traces:
      processors: [tail_sampling]
      exporters: [otlphttp/helix]

What we still recommend the native agent for

Continuous profiling with sub-1% overhead still needs our native sampler for now — the OTel profiling exporter works but at roughly 3x the overhead of ours, because the spec doesn't yet standardize our sampling technique. We're upstreaming that work, but until it lands, profiling-heavy workloads still get the native agent recommendation.

Migrating without a rewrite

For teams already running the OTel Collector, moving to full parity is a config change, not a code change — swap the exporter endpoint, add the tail-sampling processor, and existing instrumentation keeps working untouched. One customer migrated their entire trace pipeline off the native agent in an afternoon, keeping their existing OTel SDK instrumentation exactly as it was, and only noticed the difference when their vendor lock-in concerns from a prior board review quietly stopped being relevant.

What this means for how we pitch the product

It also changes an honest conversation we have with prospects during evaluation: we no longer have to ask anyone to rip out an existing OpenTelemetry investment to get our best features, which used to be a real objection in nearly every technical evaluation call. The remaining pitch for the native agent is narrower and more specific now — lowest-overhead profiling, full stop — rather than a blanket "you'll get more if you switch everything to us."

  • Full tail-based sampling and trace/metric/log parity via pure OpenTelemetry
  • No native agent required for the vast majority of workloads
  • Native agent still recommended for lowest-overhead continuous profiling
  • Standard OTLP endpoint, standard Collector config, no vendor SDK lock-in