The 2026 Prometheus and OpenTelemetry interoperability survey is out on the OpenTelemetry blog. It collected 186 responses (81 after filtering for end users running OTel for metrics with a Prometheus-like backend) and compares them with the 2024 edition. Short version: the experience has improved, but the underlying friction is still there.
What changes
The numbers I find most useful, as the project publishes them:
- Ease of use: the average rating goes from 3.1 to 3.6 out of five between 2024 and 2026. Respondents calling it hard drop from 29% to 10%, and nobody picked "very hard" (7% did in 2024). Caveat: the sample is not identical, as employer was not asked in 2024.
- Infrastructure: Prometheus exporters (72%), OTel receivers (57%), built-in
/metrics(43%) and built-in OTLP push (26%). 49% mix both styles. - Applications: OTel SDK (65%) and Prometheus SDK (52%). 41% use OTel only and 31% combine both.
- Processing: Prometheus relabeling (54%) and the open-source OTel Collector (53%). 65% run a "vanilla stack" with no commercial tooling or modifications.
Open-ended answers cluster into three themes: differing data models (attributes vs labels), gaps in resource attributes and metadata, and friction in metric naming and formats. People also ask for native Prometheus recording rules inside the Collector.
The Prometheus maintainers respond with a plan: take attribute and label unification to the October Prometheus developer summit, move forward the native metadata design (which depends on finishing OTel's Entities specification), and work so that OpenMetrics 2.0, PromQL with UTF-8 names and the OTLP receiver translation strategies become the defaults. There is also a proposal with a proof of concept for scrape-time recording rules, and the Prometheus MCP project has been brought into the Prometheus repository.
Why it matters in production
Almost half of respondents live in a hybrid model, which is exactly where the operational pain concentrates: the same service emits metrics through two paths with different naming conventions, and dashboards and alerts end up with queries that depend on how each metric was translated along the way.
Three practical consequences:
- Names are not stable by default. Until the OTLP receiver translation strategies become the default, a config change can rename series and break alerts without anything failing at deploy time.
- Resource metadata gets lost or flattened. If you aggregate on resource attributes (cluster, namespace, service version), check how they arrive as labels in your backend.
- There is no single "right" way. Platform and SRE teams tend to prefer open-source compatible backends while dev teams prefer Prometheus, but the survey itself frames this as a small-sample observation, not a firm conclusion.
Read the numbers with care: the sample is small, filtered and mixes very different organisations. Still, real usage data on this topic is rare.
What I would do
- Inventory which path each key metric takes (exporter, OTel receiver, SDK) and document the naming convention it follows.
- Test UTF-8 name translation in a staging environment before enabling it in production, and review alerts that rely on dotted names or unit suffixes:
# check which series your backend actually exposes for a service
curl -sG "$PROM_URL/api/v1/series" --data-urlencode 'match[]={job="my-service"}' | jq '.data | length'- Set the OTLP receiver translation strategy explicitly in config instead of relying on a default that may change.
- If you need recording rules on data flowing through the Collector, follow the scrape-time rules proposal before building an intermediate TSDB.
- Read or join the #otel-prometheus channel on CNCF Slack if your case matches the issues described.