Prometheus與OTel互通性：評分兩年3.1升3.6
OpenTelemetry Blog · 2026-09-22
背景：兩年前後的同一份調查
OpenTelemetry官方在2026年9月22日發布最新調查，針對同時使用OpenTelemetry與Prometheus相容後端的維運團隊做問卷，並與2024年同類調查對照。這次共有186人回覆，篩選後留下81位符合「主動使用OpenTelemetry做metrics、且後端為Prometheus系」的樣本，並排除可觀測性廠商員工以聚焦真實使用者。受訪者中有48%自評為專家級可觀測性成熟度，46%使用原生Prometheus、42%使用Thanos、Cortex、Mimir等相容後端。
過去兩者互通的根本問題出在資料模型不對齊：Prometheus的exposition格式長期只允許[a-zA-Z_:][a-zA-Z0-9_:]*這種ASCII命名，而OpenTelemetry習慣用點號分隔的資源屬性（例如service.name、process.cpu.seconds），兩邊的標籤與屬性也沒有統一映射規則。這造成的直接後果，就是團隊得手動寫轉換規則，才能讓兩套系統的指標互相看懂對方。
調查結果細節：易用度從3.1升到3.6靠什麼
五分量表的整體易用度平均分從2024年的3.1升到2026年的3.6，覺得「兩者難以搭配使用」的比例則從29%降到10%。推動這個轉變的關鍵機制是OpenMetrics 2.0規範新增的雙引號寫法，讓不符合傳統ASCII命名的指標與標籤名稱（含UTF-8字元、點號分隔字串）可以合法出現，例如{"process.cpu.seconds","service.name"="my_service"}，直接對齊OpenTelemetry的命名習慣。同時Prometheus的OTLP接收端也加入可設定的轉換策略，讓OTLP送進來的資料按需要轉成Prometheus慣用格式或原樣保留。
| 調查項目 | 2024 | 2026 |
|---|---|---|
| 易用度平均分（五分制） | 3.1 | 3.6 |
| 覺得「難以搭配使用」 | 29% | 10% |
| 回答「非常困難」 | 7% | 0% |
| 回答「有點困難」 | 22% | 10% |
| 回答「普通」 | 37% | 40% |
| 回答「有點容易」 | 26% | 33% |
| 回答「非常容易」 | 8% | 17% |
不過分數還沒完全解決的部分很明顯。「普通」這個中性選項仍是2026年最大的一群，占40%，代表磨擦感還在；開放題裡最常被點名的問題是「統一Prometheus與OpenTelemetry的資料模型」，這項議題已排入10月Prometheus Dev summit討論。另外資源屬性與中繼資料的落差，被追溯到OpenTelemetry的Entities規範還沒完成；文章也坦言，UTF-8命名與OTLP轉換策略雖然存在，但都還不是預設值，需要維運團隊自己動手開啟。
影響範圍：純Prometheus團隊該檢查什麼
- 確認後端版本是否已支援OpenMetrics 2.0的雙引號UTF-8語法，否則點號命名的OTel指標仍會被拒收或改名
- 檢查Prometheus設定裡OTLP接收端的轉換策略是否符合團隊需求，而不是沿用預設行為
- 盤點現有的relabeling／recording rules，調查顯示54%的團隊仍靠這條路徑做轉換，並非人人都已切換到OTel Collector
- 追蹤10月Prometheus Dev summit對資料模型統一與Entities規範的討論，這會決定未來標籤映射是否有官方標準
調查也顯示，基礎設施層有72%團隊仍在用Prometheus exporter、57%用OTel receiver，將近一半的人是兩者並存而非二選一遷移。這代表混合架構已經是常態，而非過渡期的權宜之計，還在猶豫要不要導入OTel的團隊，可以先從應用層SDK或Collector轉換規則局部導入，不必整套換掉現有Prometheus生態。100人以上規模的組織中，OTel SDK採用率達到84%，顯示規模越大的團隊採用OTel的比例越高。