OpenTelemetry and Prometheus finally converge, and the 2026 numbers confirm it
A 2026 survey shows interoperability between OpenTelemetry and Prometheus has improved markedly: the ease-of-use score climbed from 3.1 to 3.6, and the share who find them hard to combine fell from 29% to 10%. For an SRE team still on the fence, now is the time to consolidate on the OTel Collector without abandoning Prometheus.
September 22, 2026. A survey on OpenTelemetry/Prometheus interoperability is published: nearly half of respondents mix both instrumentations for their infrastructure metrics. September 23, 2026. Atlassian documents its migration of 100,000 hosts to OpenTelemetry on the CNCF blog. September 23, 2026. New Relic releases its 2026 Observability Forecast, which finds 73% of teams standardized on OTel. Why it matters: after two years of work, the two dominant observability ecosystems have stopped being rivals and become complements — and the architecture decision is simple again.
Two standards that used to turn their backs on each other
OpenTelemetry and Prometheus occupy the same ground without always having cohabited well. Prometheus remains the reference for infrastructure metrics, with its scrape model and PromQL query language. OpenTelemetry, a CNCF project that graduated in May 2026, has become the universal instrumentation and collection layer, carried by a Collector that can receive, transform, and export telemetry.
For a long time, teams had to pick a side or pay for costly double instrumentation. The 2026 interoperability survey measures exactly that point: roughly half of respondents mix Prometheus and OTel instrumentation for infrastructure metrics, and 30.7% use both for application metrics. The hybrid setup is no longer the exception — it is the norm.
The numbers that say it works
The progress shows up in two indicators. The average ease-of-use score for the pair rose from 3.1 to 3.6 on the survey’s scale, a 0.5-point gain. More tellingly, the share of those who find the two tools hard to combine fell from 29% to 10%.
The contributors behind the rapprochement put it plainly. Dhruv Ahuja of SigNoz, Andrej Kiripolsky and Arthur Sens of Grafana Labs, and Ana Muenz write: “Two years of work on interoperability is paying off.” Identified work remains: better alignment between the projects’ data models, cleaner handling of resource attributes and metadata, and fewer naming and formatting issues. That residual friction is real but manageable, and it no longer blocks the two tools from running side by side.
Atlassian’s proof: 100,000 hosts migrated
The Atlassian case turns the promise into a measured result. The company migrated its metrics collection from gostatsd, its open-source implementation of Etsy’s StatsD protocol, to OpenTelemetry. The original pipeline, which handled metrics from roughly 100,000 hosts across 14 regions, was increasingly out of sync with the broader shift to OTel: “It became the thing everyone standardized on, and more and more of what fed our pipeline was emitting OTel data we simply didn’t support,” the engineers write.
The approach was to swap the collection and pipeline mechanics underneath while keeping the service-facing interface unchanged. The result was an organization-wide overhaul that became what the authors call a “platform-team migration.” The gains are measurable: aggregation now uses about half the CPU for the same traffic, CPU usage is more evenly distributed across ingest shards, and sidecar costs are down roughly 30% at fleet scale.
The cost of unobservability, per New Relic
New Relic completes the picture with its 2026 Observability Forecast, based on 2,575 leaders and practitioners surveyed. The report confirms that 73% of organizations are standardized on OTel, actively migrating to it, or testing it. It also ties observability to AI adoption: 83% of respondents consider observability essential for AI-generated code, and organizations that monitor their AI agents are twice as likely to see a threefold return on observability investment.
The cost of going without observability is quantified. Engineers now spend 37% of their time addressing disruptions, and 42% of organizations learn about disruptions through inefficient channels — manual checks or customer complaints. New Relic estimates the average loss from high-impact outages at $74 million a year, or $1.85 million per hour and more than $30,000 per minute of downtime.
The pattern that emerges
The convergence yields a legible architecture. Prometheus remains the storage and alerting foundation for infrastructure metrics, while the OTel Collector becomes the single gateway that receives, transforms, and routes all telemetry. The two connect through Prometheus’s remote write exporter, avoiding double instrumentation while keeping PromQL and the existing alerting ecosystem.
receivers:
otlp:
protocols:
grpc:
http:
exporters:
prometheusremotewrite:
endpoint: "http://prometheus:9090/api/v1/write"
service:
pipelines:
metrics:
receivers: [otlp]
exporters: [prometheusremotewrite]The road ahead is predictable: Prometheus v3.15 has entered release candidate with performance improvements, and the convergence should keep tightening on the two remaining fronts — data model alignment and resource attribute handling.
Why now
This catch-up is not a quirk of the calendar. OpenTelemetry graduated from the CNCF in May 2026, a maturity signal that accelerated production adoption. Graduation also freed the energy needed to smooth the rough edges with Prometheus: the two projects now share contributors and a roadmap around data model alignment.
The mechanism is technical. The OTel Collector ships a mature Prometheus receiver and exporter, and the OTel metrics data model has converged toward Prometheus conventions — metric names, labels, HTTP exposition. What used to be a lossy translation between two formats has become a stable bridge, and that bridge is what makes double instrumentation unnecessary.
For teams, the practical consequence is that running Prometheus for infrastructure metrics and OTel for application and agent telemetry is no longer a compromise to be apologized for — it is a supported, recommended pattern with a two-year track record behind it. For most teams the deciding factor is no longer technical but organizational: standardizing on OTel means one instrumentation layer to teach, one collector to run, and one migration to plan.
Observability for AI agents, the new frontier
The OTel/Prometheus convergence lands just as observability changes target. New Relic’s 2026 Observability Forecast ties observation maturity directly to AI success: organizations that monitor their AI agents get a better return than those that let them run unsupervised. An agent executing production tasks emits metrics, traces, and logs like any service — but with an extra dimension: you want to know not only whether it is slow, but whether it did what was expected.
That is where OpenTelemetry finds its strongest justification. Its vendor neutrality makes it the natural layer for instrumenting agents whose behavior must be audited, not merely watched. Prometheus remains downstream to store those signals and fire the alerts. The two ecosystems are not only reconciled: they are dividing roles on the newest front of observability. As AI agents move out of the sandbox and into production, the question is no longer which of OTel or Prometheus to choose, but how to wire them together early enough to audit what the agents actually do.
Verdict
If you are already on Prometheus and hesitating to adopt OTel for application metrics, go for it: the two are no longer competitors, and the OTel Collector with the remote write exporter spares you double instrumentation. If you are starting a greenfield project, standardize instrumentation on OTel and keep Prometheus for storage and alerting — that is now the lowest-risk path. If you are mid-migration, borrow from Atlassian: replace the collection mechanics beneath the existing interface, and measure aggregation CPU before and after. The verdict is no longer “pick a side” — it is “consolidate on OTel, and keep Prometheus where it excels.”