OpenTelemetry’s latest Prometheus interoperability survey lands at a useful moment for platform teams: the metrics migration story is no longer a simple choice between an older Prometheus estate and a newer OpenTelemetry pipeline. The strongest signal from the survey is that many production teams are settling into a hybrid operating model, with Prometheus-style collection still deeply embedded in infrastructure monitoring while OpenTelemetry takes a larger role in application instrumentation and metadata normalization.
That matters because metrics architecture has become one of the places where cloud native standardization either reduces operational load or quietly creates a new layer of translation work. The survey, published by the OpenTelemetry project on September 22, reports that users find the two ecosystems easier to use together than they did in 2024. Yet the same data also shows that most organizations are not doing a clean replacement. They are running both styles because each solves a different part of the observability problem well.
The practical takeaway is not that Prometheus is fading or that OpenTelemetry has completed the metrics transition. It is that the next stage of cloud native observability will be judged by how well teams can preserve Prometheus’ reliability and query culture while using OpenTelemetry to carry richer context across Kubernetes, services, and vendors.
The Survey Shows Progress, Not Completion
The OpenTelemetry survey analyzed responses from 81 active OpenTelemetry-for-metrics users who also use a Prometheus-adjacent backend, after filtering out observability vendor employees. That sample is not a census of the whole market, but it is especially relevant because it focuses on teams already living with the Prometheus and OpenTelemetry overlap.
The headline improvement is real. OpenTelemetry reports that the average ease-of-use rating for using Prometheus and OpenTelemetry together rose from 3.1 in the 2024 survey to 3.6 in 2026 on a five-point scale. The share of respondents who found the combination hard to use fell from 29% to 10%, and no respondent in the filtered 2026 sample selected “very difficult.” For an area that has historically been full of naming, data model, temporality, and metadata friction, that is meaningful progress.
But the survey also makes clear that easier interoperability is not the same as a finished convergence. The largest response group still sits at “neither easy nor difficult.” That middle category is important: it suggests that teams can make the systems work together, but still need enough engineering judgment, collector configuration, relabeling, and backend-specific knowledge that the combination is not yet invisible infrastructure.
For platform leaders, that should temper both extremes. Treating OpenTelemetry metrics as too immature ignores the progress shown by users already running it. Treating interoperability as solved risks underestimating the operational burden of mixed pipelines, especially when metric names, labels, resource attributes, and query semantics need to remain stable for dashboards and alerts.
Infrastructure Metrics Remain Prometheus-First
The most revealing split in the survey is between infrastructure and application instrumentation. For infrastructure metrics, Prometheus exporters remain the most-used method at 72%. OpenTelemetry receivers are close behind at 57%, while built-in /metrics endpoints appear in 43% of responses. Nearly half of respondents mix Prometheus and OpenTelemetry instrumentation styles for infrastructure rather than choosing one model exclusively.
That result should not surprise Kubernetes operators. Prometheus exporters and scrape targets are woven into the cloud native ecosystem. Node, ingress, database, queue, storage, and control-plane components often expose metrics in Prometheus formats because that is what operators, Helm charts, service monitors, and alerting rules have expected for years. Removing that machinery rarely creates immediate business value.
OpenTelemetry’s role in infrastructure is therefore less about displacing every exporter and more about absorbing, enriching, and forwarding metrics consistently. The Collector can receive Prometheus data, reshape it, attach resource context, and send it to different storage backends. That makes it useful in organizations that are standardizing telemetry pipelines, even while the original collection surface remains Prometheus-native.
The survey’s hybrid infrastructure pattern is also a warning against architectural purity. A platform team that demands an immediate migration away from existing exporters may burn time recreating stable monitoring paths. A team that ignores OpenTelemetry entirely may find it harder to join infrastructure signals with traces, logs, and application metrics later. The winning pattern for many organizations is likely to be coexistence with clear ownership boundaries: Prometheus-style collection where it is mature and cheap, OpenTelemetry processing where cross-signal context and portability matter.
Application Metrics Are Moving Faster Toward OpenTelemetry
Application instrumentation tells a different story. The survey found that OpenTelemetry SDKs are the most-used application metrics method at 65%, ahead of Prometheus SDKs at 52%. It also found that 41% of respondents use only the OpenTelemetry style for application instrumentation, while fewer than a third mix styles.
This is where OpenTelemetry has a natural advantage. Application teams increasingly want one instrumentation model for traces, metrics, and logs, and they want libraries that can carry service, deployment, runtime, and request context without each signal being configured as a separate island. If a new service is already adopting OpenTelemetry for distributed tracing, adding application metrics through the same instrumentation family is easier to justify than adding a Prometheus client solely for metrics.
This split has consequences for standards work. If applications increasingly emit OpenTelemetry-native metrics while infrastructure remains full of Prometheus exporters, then interoperability must work in both directions. Teams need reliable mappings between attributes and labels, predictable metric names, and backends that do not force every migration decision to become a dashboard rewrite.
The Collector Is Becoming the Negotiation Layer
The survey’s transformation data shows why the OpenTelemetry Collector is becoming central to metrics strategy. Prometheus relabeling and recording rules were used by 54% of respondents, while the open source Collector was used by 53%. Most respondents run what OpenTelemetry calls a “vanilla stack”: Prometheus relabeling rules, the plain Collector, or both, without a vendor distribution or a custom-built Collector in the path.
That is a healthy signal for the ecosystem. It means many teams are trying to solve interoperability with upstream primitives before reaching for proprietary transformation layers. It also suggests that the operational center of gravity is not only the storage backend, but the processing layer where telemetry is filtered, enriched, renamed, and routed.
The risk is that this layer can become a dumping ground for accidental complexity. Relabeling rules are powerful, but they can become opaque when they encode years of local assumptions. Collector processors can standardize pipelines, but they can also create a second configuration surface that only a small platform group understands. The more a team depends on transformation to make metrics usable, the more it needs tests, ownership, and change control around that configuration.
OpenTelemetry’s own related milestones show why the Collector layer is getting more serious. The Kubernetes attributes processor reached v1.0.0 this month, with the project saying the component now meets stable criteria around testing, benchmarking, documentation, and telemetry stability. That processor enriches telemetry with Kubernetes metadata, and its stabilization depended on related Kubernetes semantic conventions becoming stable. In other words, the metadata layer that helps metrics make sense in Kubernetes is being treated as production API surface, not as an experiment.
That matters for Prometheus interoperability because much of the remaining friction lives in metadata. Users cited unification of attributes and labels, resource attribute handling, and naming or formatting issues as areas needing improvement. A stable Kubernetes attributes processor does not solve every mapping problem, but it strengthens a key building block for making telemetry from pods, services, namespaces, nodes, and workloads more consistent across pipelines.
Prometheus Is Still Evolving Around the Same Pressure Points
The Prometheus side of the ecosystem is also moving. The Prometheus 3.15.0 release candidate includes changes that matter to operators running large metric estates: scrape support for Unix Domain Sockets, an OM 2.0 scrape format implementation, zstd-compressed scrape responses behind a feature flag, more tracing spans for scrapes and queries, and TSDB improvements including stabilized XOR2 float chunk encoding. The release candidate also includes a long list of bug fixes across PromQL, TSDB, native histograms, discovery, and remote write paths.
Those release notes are not merely housekeeping. They show Prometheus continuing to adapt for denser, more varied, and more performance-sensitive environments. Compression, chunk encoding, native histogram handling, remote write behavior, and service discovery resilience all affect the cost and reliability of running metrics at cloud native scale.
For teams using OpenTelemetry alongside Prometheus, those Prometheus changes are part of the same interoperability story. A Collector pipeline cannot compensate for a metrics backend that is too expensive to query, a scrape path that is brittle, or query semantics that surprise operators. Likewise, Prometheus improvements do not remove the need for richer resource context and cross-signal correlation. The systems are converging in practice because users need both sets of strengths.
What Platform Teams Should Do Now
The survey points to a pragmatic operating model for the next year. First, teams should inventory where Prometheus-style and OpenTelemetry-style metrics already exist, separating infrastructure collection from application instrumentation. Treating the whole estate as one migration problem will produce the wrong plan because the adoption patterns are different.
Second, platform groups should define a small set of rules for metric identity. Which labels are allowed to become high-cardinality attributes? Which Kubernetes attributes are required on service metrics? Which names are stable enough to appear in alerting rules? Which transformations are allowed in the Collector, and which belong closer to the source? These questions are less exciting than picking a backend, but they determine whether observability stays usable after the first migration wave.
Third, teams should protect existing alert reliability while they modernize. The survey suggests many users are mixing systems rather than replacing one with the other. That is sensible, but mixed systems can create duplicate series, inconsistent labels, or subtly different aggregations. Before moving critical alerts onto a transformed pipeline, teams should compare outputs over time and document any intentional differences.
Fourth, organizations should avoid unnecessary vendor lock-in at the transformation layer. The survey’s “vanilla stack” result shows that many users can get far with upstream Collector components and Prometheus rules. Vendor backends and managed platforms may still be valuable, but the core translation logic should be understandable and portable where possible.
Finally, platform teams should track stability milestones, not just feature launches. The Kubernetes attributes processor reaching v1.0.0 is a better signal for production adoption than a flashy integration announcement because it says the component’s behavior, documentation, and compatibility expectations are becoming firmer. Similar milestones across Collector components, semantic conventions, and Prometheus features will matter more than broad claims about unified observability.
The New Baseline Is Coexistence
The OpenTelemetry and Prometheus relationship has moved beyond the early question of whether the two projects can work together at all. According to the survey, users report measurable improvement, and fewer find the combination difficult. But the more important finding is that coexistence has become normal. Infrastructure metrics remain heavily Prometheus-shaped. Application metrics are moving faster toward OpenTelemetry. The Collector and relabeling rules sit between them as the practical translation layer.
That is good news for cloud native teams, provided they treat interoperability as an engineering discipline rather than a checkbox. The goal is not to erase Prometheus history or force every workload through one idealized telemetry path. The goal is to make metrics portable enough, contextual enough, and stable enough that teams can change pipelines without losing operational trust.
OpenTelemetry’s latest survey suggests the ecosystem is closer to that goal than it was two years ago. The next test is whether the remaining friction around labels, attributes, naming, and metadata can be reduced without making the pipeline harder to operate than the systems it is meant to connect.
