OpenTelemetry and Prometheus Interop: Surveys Show Progress

Two surveys, one ecosystem

The open source observability stack is maturing, though not evenly. Two recent community surveys give a data-driven look at how teams collect and process telemetry. One comes from the Prometheus project, and the other is a follow-up survey on the OpenTelemetry Collector. Together they suggest that the long-running friction between Prometheus and OpenTelemetry (OTel) is easing. They also show that the tooling around building and running Collectors at scale still leaves many users unconvinced.

Interoperability is paying off

The Prometheus survey, published September 21, 2026, asked OTel and Prometheus users how they collect, process and store metrics. The goal was to replace assumptions with real usage data and to measure whether interoperability still causes friction 2. The authors' headline conclusion is upbeat. They say two years of interoperability work is paying off, and ease-of-use responses have improved over time 2.

The processing data shows how intertwined the two projects have become. Prometheus relabeling rules (54%) and the open source OTel Collector (53%) are the two most common processing steps. Sixty-five percent of respondents run what the authors call a "vanilla stack": one or both of those tools, with no vendor transformation or custom Collector build anywhere in the pipeline 2.

The respondent pool was experienced. Forty-eight percent described their organizations as having a well-established observability practice. Another 41% said they were still setting one up, and only 11% identified as beginners 2. Experienced practitioners tend to be the harshest critics of rough edges, so improving sentiment from this group carries weight. It also means the results may say less about how newcomers find the onboarding experience.

The Collector keeps growing, and growing more complex

The OpenTelemetry Collector follow-up survey shows deployments continuing to scale. Sixty-five percent of respondents now run more than 10 Collectors, a 10-point increase. The share running between two and five fell by 7 points to 15% 1. Kubernetes remains the dominant environment at 81%, but virtual machine usage jumped from 33% to 51% 1. Mixed environments are common. About a quarter of smaller deployments and roughly half of large ones run Collectors on both Kubernetes and VMs 1.

Workload patterns differ by size. Organizations running more than 100 Collectors collect more metrics and logs, while smaller ones lean toward traces 1. Component usage is shifting as well. The OTLP HTTP exporter, Datadog exporter and connector, file log receiver, Kubernetes cluster receiver, attributes and transform processors, routing connector, and file storage extensions all saw increased adoption. The memory limiter processor declined 1.

The more pointed finding concerns custom builds. An additional 13% of respondents now build their own Collector, yet 61% of OTel users would not say the OpenTelemetry Collector Builder is easy to use 1.

Where the surveys diverge

At first glance, the two datasets seem to pull in different directions. The Prometheus survey highlights a majority running stock tooling with no custom builds 2. The Collector survey shows custom builds rising and a builder tool most users find difficult 1.

The likely explanation is that the two surveys capture different slices of the community. A metrics-focused team bridging Prometheus and OTel can often get by with off-the-shelf components. Teams operating large, multi-environment Collector fleets are more likely to need tailored distributions, and that is where the tooling bites. In practice, interoperability at the protocol and data level is improving faster than the operational ergonomics of the Collector itself.

Broader context

The project appears aware of the pressure. Coverage earlier in 2026 pointed to an OpenTelemetry roadmap focused on sampling rates and Collector improvements 3. Meanwhile, the wider observability market is moving toward AI. Dynatrace is pitching AI agents that fix problems rather than add alerts, and it acquired Arize on the argument that agents require a new kind of observability 3. Large-scale engineering efforts, such as AWS Lambda's eBPF- and Rust-based logging across microVMs, show how much telemetry volume production systems now generate 3.

The takeaway

The broad trend is positive. Prometheus and OpenTelemetry are converging into a workable default stack, and experienced users report it is getting easier. But the Collector's growth into VMs, hybrid estates and custom builds is creating a new layer of complexity. The 61% who don't find the Collector Builder easy to use 1 mark the next friction point to resolve. The next phase for the project is less about whether Prometheus and OTel can work together and more about whether running OTel at scale can become routine.