OTel 與 Prometheus 互通調查：易用度升至 3.6，資料模型統一仍待討論
OpenTelemetry Blog · 2026 年調查（頁面未標示發布日期）
OpenTelemetry（OTel）與 Prometheus 的互通性，不再是兩年前那種「勉強能接」的狀態：同一份問卷在 2024 年給出平均 3.1 的易用度，2026 年升到 3.6。這是 OTel 社群針對「Prometheus 相鄰後端上的 OTel metrics 使用者」做的第二次調查，共 186 人作答，其中 81 人通過篩選，且已排除廠商員工。
原本的問題
OTel 與 Prometheus 的資料模型不同：OTel 有 resource attributes 與 OTLP 格式，Prometheus 則是 label 加上 exposition format 的命名慣例。兩邊要混用，就得靠轉換規則、relabeling 或 Collector 來橋接。2024 年的第一次調查顯示，這個橋接對不少人仍是痛點。
這次的受訪者全部使用某種 Prometheus 系後端：Prometheus 本身 46%、開源的 Prometheus 相容後端 42%、支援 PromQL 的廠商產品 12%。經驗上 48% 自評 Expert、41% Intermediate、11% 初學者。
易用度的變化
覺得困難的人從 29% 降到 10%，而且 2026 年沒有人選「非常困難」。文章指出，若把廠商員工（n = 108）算進來，結果幾乎不變。
| 回答 | 2024 | 2026 |
|---|---|---|
| 非常困難 | 7% | 0% |
| 有點困難 | 22% | 10% |
| 中立 | 37% | 40% |
| 有點容易 | 26% | 33% |
| 非常容易 | 8% | 17% |
實際的混用方式
基礎設施端的 metrics 仍以 Prometheus exporter（72%）為主，OTel receiver 為 57%，內建 /metrics 端點 43%，內建 OTLP push 26%。收集風格上，49.4% 是兩者混用，30.4% 只用 Prometheus，15.2% 只用 OTel。
應用程式端則反過來：OTel SDK 65%，Prometheus SDK 52%。風格上 41.3% 只用 OTel，30.7% 混用，22.7% 只用 Prometheus。換句話說，應用程式往 OTel 靠，基礎設施仍留在 Prometheus exporter 生態。
- 轉換層：Prometheus relabeling 與 recording rules 54%，開源 OTel Collector 53%，廠商 Collector 發行版 11%，自建 Collector 10%，什麼都不做 15%。
- 約 65% 跑的是「vanilla」堆疊，也就是只用 Prometheus 規則和（或）開源 Collector。
文章另外提出兩個假設，樣本數只有每組 8 到 35 人：100–999 人的中型組織 OTel SDK 採用率最高（84%）；Platform Engineering 與 SRE 團隊選開源 Prometheus 相容後端的比例為 69%，開發團隊選純 Prometheus 的比例為 71%。這些只是樣本內的觀察，不宜當成定論。
維護者的回應
開放式回饋共 19 則，歸成三類，Prometheus 維護者 Krajo Krajcsovits 與 Arthur Sens 逐項回應。
- 統一資料模型：維護者稱這是「valid ask」，會在 10 月的 Prometheus Dev Summit 提出討論。
- resource attributes 與 metadata：預定解法是native metadata 設計文件，但要等 OTel Entities spec 完成。
- 命名與格式摩擦：OpenMetrics 2.0 允許直接使用 OTel 風格名稱，PromQL 已支援 UTF-8 指標名稱，Prometheus 的 OTLP receiver 有可設定的 translation strategy。維護者的說法是「零件都在，只是還不是預設值」。
個別需求也有進展：scrape 階段的 recording rules 有提案 PR #67 與概念驗證 PR #10529，不需要完整 TSDB，Collector 的 Prometheus Receiver 因為以 Go library 方式使用 Prometheus 程式碼，也能受益。Prometheus MCP 已併入 Prometheus GitHub org。把 Prometheus exporter 做成 Collector 發行版，則仍在issue 1618 討論，文章寫的是「對話仍在進行中」。
影響範圍
如果你的 Prometheus 是 OTLP 的落地端，現在值得檢查的是 OTLP receiver 的 translation strategy 設定，因為預設命名未必符合你想要的 OTel 風格。維護 Collector 的團隊則可以追蹤 PR #67 與 issue 1618，兩者都還沒定案，文章也沒有給出時程。resource attributes 的原生支援要等 Entities spec，短期內仍要靠 relabeling 與 Collector 處理。
原始來源：OpenTelemetry Blog 調查報告、2024 年調查、Prometheus proposal PR #67