A new OpenTelemetry community survey offers a useful correction to a familiar observability narrative: Prometheus and OpenTelemetry are not racing toward a winner-takes-all finish. They are settling into a shared metrics architecture in which each project does the job teams already trust it to do.
The survey, published in September 2026, found that using the two projects together has become measurably easier since 2024. At the same time, adoption patterns remain deliberately mixed. Prometheus exporters still dominate infrastructure collection, OpenTelemetry SDKs lead application instrumentation, and the processing layer is almost evenly split between Prometheus rules and the open source OpenTelemetry Collector.
That combination matters more than a simple adoption ranking. It suggests the practical endpoint for many Kubernetes and cloud native teams is not a wholesale migration from Prometheus to OpenTelemetry. It is a stable division of labor: preserve Prometheus-compatible metrics and PromQL workflows while using OpenTelemetry as the increasingly common instrumentation and transport layer.
The headline is coexistence, not replacement
The survey analyzed 81 active OpenTelemetry metrics users running Prometheus or a Prometheus-adjacent backend. It excluded observability vendor employees and drew heavily from mature organizations: 48% described their observability practice as established, and 42% worked at companies with at least 1,000 employees.
Within that experienced sample, the average rating for ease of use between OpenTelemetry and Prometheus rose from 3.1 out of five in 2024 to 3.6 in 2026. The share describing the combination as difficult fell from 29% to 10%, while nobody selected “very difficult.” The comparison is not perfectly controlled because the earlier survey did not identify vendor employees, but the authors report that including vendors in the 2026 results would barely change the ease-of-use distribution.
The improvement is real, but it does not mean the projects have become interchangeable. The largest group still rated interoperability as neither easy nor difficult. More importantly, respondents chose different tools at different points in the pipeline.
For infrastructure metrics, 72% use Prometheus exporters and 57% use OpenTelemetry receivers. Nearly half mix Prometheus-style and OpenTelemetry-style infrastructure instrumentation. Among teams that use only one style, Prometheus-only remains roughly twice as common as OpenTelemetry-only.
Application instrumentation reverses the order. OpenTelemetry SDKs are used by 65% of respondents, compared with 52% for Prometheus SDKs, and 41% rely exclusively on OpenTelemetry-style instrumentation for applications. That is the clearest sign of where the boundary is forming: existing infrastructure integrations favor the vast Prometheus exporter ecosystem, while new application code increasingly starts with vendor-neutral OpenTelemetry APIs and SDKs.
Why the split makes architectural sense
Prometheus built its strength around a pull-based operating model, a huge catalog of exporters, a durable time-series data model, and PromQL. Kubernetes operators understand its service discovery, scraping, alerting, and recording-rule workflows. Replacing that installed base would create risk without necessarily improving the questions teams can ask of their metrics.
OpenTelemetry addresses a different layer. It standardizes how applications create telemetry, how agents and collectors receive it, and how signals are processed and exported. Its value increases when an organization wants consistent instrumentation across metrics, traces, logs, and profiles, or needs the freedom to route data to more than one backend.
The two models meet through several paths. The OpenTelemetry Collector can scrape Prometheus endpoints, and Prometheus can accept metrics pushed over OTLP/HTTP when its receiver is explicitly enabled. Translation rules cover counters, gauges, histograms, native histograms, summaries, exemplars, and instrumentation scope. These are not merely adapters at the edge; they represent a shared compatibility layer that preserves enough meaning for teams to choose components independently.
This is why the survey’s mixed deployments should not be read as unfinished migrations. A Kubernetes platform may scrape node and database exporters through a Collector, accept OTLP from application SDKs, apply selected transformations, and store everything in a Prometheus-compatible backend. That architecture uses both ecosystems by design. Removing either one could reduce capability rather than reduce complexity.
The processing layer is the new decision point
The most revealing result may be what happens between collection and storage. Prometheus relabeling and recording rules are used by 54% of respondents; the open source OpenTelemetry Collector is used by 53%. Sixty-five percent run what the survey calls a “vanilla stack”: Prometheus rules, the standard Collector, or both, without a vendor distribution or a custom Collector build in the pipeline.
That is a strong signal for platform teams evaluating elaborate telemetry architectures. The mainstream pattern is not a heavily customized observability mesh. It is a relatively plain combination of community components, with transformation placed where the team already has operational skill.
Prometheus rules remain effective for metric-specific concerns: dropping labels, rewriting targets, precomputing expensive queries, and keeping cardinality under control close to the backend. The Collector is better positioned for pipeline concerns: receiving multiple protocols, enriching signals with resource context, filtering telemetry, batching exports, and routing data to multiple destinations.
The risk comes from duplicating policy across both. If a label is renamed in the Collector and then rewritten again in Prometheus, dashboards become harder to reason about. If aggregation happens at several stages, operators may not know which representation is canonical. Convergence therefore increases the need for a clear ownership model even as it reduces protocol friction.
The hard problems have moved up the stack
Interoperability is no longer primarily about whether one system can ingest the other’s wire format. The survey’s open-ended responses point to subtler gaps: differences between attributes and labels, incomplete handling of resource metadata, and naming or formatting surprises.
These details determine whether a metric remains useful after translation. OpenTelemetry models resource attributes separately from individual data-point attributes, while Prometheus has historically represented identifying context through labels and target metadata. A technically successful conversion can still produce awkward queries, unexpected names, or excessive cardinality if teams promote every resource attribute indiscriminately.
Prometheus documentation reflects that tradeoff. Its OTLP receiver is disabled by default because a Prometheus server may run without authentication, making an exposed ingestion endpoint unsafe. Once enabled, operators must choose which resource attributes become labels and how metric names are translated. Prometheus recommends promoting a targeted set of attributes such as service identity and deployment environment rather than copying everything.
Those controls are evidence of maturing interoperability, not signs that translation is automatic. Platform teams still need conventions for service names, namespaces, cluster identity, units, histogram behavior, and label budgets. The protocol bridge can carry data; it cannot decide which organizational semantics are correct.
What Kubernetes platform teams should do now
The survey supports an incremental strategy rather than a forced migration program.
- Keep proven exporters. If a database, node, or controller exporter is reliable, there is little reason to replace it solely to claim an OpenTelemetry-native stack. Receive or scrape it through the component that best fits the current operating model.
- Standardize new application instrumentation on OpenTelemetry. Its APIs and SDKs provide a better foundation for correlating metrics with traces and other signals while retaining backend choice.
- Choose one policy owner for every transformation. Document whether naming, resource promotion, filtering, aggregation, and cardinality controls live in application SDKs, the Collector, Prometheus rules, or the backend. Avoid implementing the same policy twice.
- Test semantic compatibility, not just delivery. A successful OTLP request does not prove that dashboards, alerts, exemplars, or histogram queries still behave correctly. Build golden queries and alerts into migration tests.
- Protect ingestion endpoints. Enabling Prometheus’ OTLP receiver changes its network exposure. Put authentication, authorization, and network policy around it rather than treating the receiver as a drop-in public endpoint.
- Measure the pipeline itself. Track rejected data points, queue growth, dropped attributes, translation failures, and series cardinality. A hybrid pipeline needs observability for its boundaries.
Teams should also resist designing around a hypothetical future in which every exporter disappears. The survey shows a large, active exporter estate coexisting with rising OpenTelemetry adoption. A platform contract that accepts both Prometheus exposition and OTLP is more realistic than one that mandates a single ingestion style for every workload.
What still needs to converge
The remaining work is concentrated in semantics and defaults. The communities are discussing closer alignment between attributes and labels, better native metadata, and more predictable naming. Existing pieces already help: PromQL supports UTF-8 metric names, Prometheus offers configurable translation strategies, and the compatibility specification defines stable mappings for major metric types. But usable defaults lag behind the underlying capabilities.
That gap creates an opportunity for the CNCF ecosystem. If common Kubernetes distributions can ship tested conventions for service identity, resource promotion, histogram conversion, and secure OTLP ingestion, teams will spend less time inventing local rules. The goal should not be to hide every difference between Prometheus and OpenTelemetry. It should be to make those differences explicit, testable, and boring to operate.
The survey is small and skewed toward mature practitioners, so it should not be treated as a census of the entire cloud native market. Its 81 analyzed respondents are more useful as a directional sample of teams already doing the integration work. Even with that caveat, the pattern is coherent across instrumentation and processing: organizations are combining the projects at multiple layers, and the experience is improving.
A durable two-project architecture
The most consequential outcome of better interoperability may be that it removes pressure to choose a single winner. Prometheus can remain the familiar metrics engine and query ecosystem. OpenTelemetry can become the common instrumentation and telemetry pipeline. Cloud native teams can modernize application signals without abandoning exporters, PromQL, or existing operational knowledge.
That is a more durable architecture than a rip-and-replace migration. It acknowledges that standards succeed when they connect valuable systems, not only when they displace them. For Kubernetes operators, the next phase of observability will be less about choosing Prometheus or OpenTelemetry and more about governing the contract between them.
