Prometheus 與 OpenTelemetry 互操作性現狀與技術重點

引言

在現代雲原生監控生態系中，Prometheus 與 OpenTelemetry 作為兩大核心工具，各自具備獨特的監控能力與生態整合性。Prometheus 以拉取式（Pull-based）模型著稱，擅長即時監控與高效資料處理；而 OpenTelemetry 則以推送式（Push-based）模式支援分散式追蹤與觀察。兩者的互操作性成為雲原生架構中關鍵的整合點，本文將深入探討其技術差異、協議改進與未來整合方向，並分析現有架構的優勢與挑戰。

主要內容

技術或工具的定義與基本概念

Prometheus 是一個開源的監控與警報系統，透過拉取式模型定期收集指標資料，並儲存於時序列資料庫（TSDB）中，支援強大的查詢語言 PromQL。其核心特性包括自動服務發現、高效資料壓縮與可擴展的儲存機制。

OpenTelemetry 是一個開放標準的觀察工具集，提供追蹤（Tracing）、度量（Metrics）與日誌（Logs）的統一框架。其推送式模型透過 OpenTelemetry Collector 收集、轉換與導出資料，支援多種協議（如 OTLP、JSON、Prometheus Exposition Format）。

重要的特性或功能

模型差異與協議整合

拉取式（Prometheus）：依賴服務發現識別監控目標，定期拉取指標資料。優點在於可監控服務狀態（如拉取失敗），但需維護指標記憶體，且資料重複拉取會浪費資源。
推送式（OpenTelemetry）：透過 Collector 推送資料至監控後端，無需服務發現，但無法區分應用程式離線與網路問題。資料僅在變動時傳送，缺乏服務狀態監控。

兩者的協議整合需透過遠端寫入（Remote Write）與資料轉換處理器，例如 Prometheus 3.0 引入 Delta to Cumulative 處理器，將 OpenTelemetry 的 Delta 指標轉換為 Cumulative 格式。

UTF-8 支援與名稱轉換

Prometheus 3.0 預設支援 UTF-8 字元集，解決 OpenTelemetry 語義約定中常見的點號（.）問題。OpenTelemetry Collector 配置需設定旗標避免預設暴露寫入資料庫的端點，並提供 UTF-8 轉換為底線（_）的名稱策略，以符合 Prometheus 的命名規範。

Delta 與 Cumulative 轉換

Prometheus 3.0 引入 Delta to Cumulative 處理器，用於將 OpenTelemetry 的 Delta 指標轉換為 Cumulative 格式，需維護狀態以計算轉換。未來計畫支援在查詢階段處理 Delta 指標，或新增 PromQL 函數以提升效率。

原生直方圖（Native Histogram）

Prometheus 3.0 引入原生直方圖，提升效能與準確性，支援單一請求內包含完整直方圖，並用於 OpenTelemetry Collector 的遠端接收器。需完善 OpenMetrics 文本格式的實現，並解決查詢集的後續需求，目前已接近穩定狀態。

遠端寫入協議 v2（Remote Write v2）

新增對原生與經典直方圖、Exemplars（連結指標與追蹤）、元數據（作用於系列而非指標名稱）、時間戳等支援。支援部分寫入統計資訊（如寫入成功/失敗資料量），並計畫整合至遠端寫入出口。

資源屬性（Resource Attributes）

當前策略將資源屬性轉換為單一指標（target_info），並透過 PromQL JOIN 結合，但 JOIN 操作被視為使用門檻。未來計畫允許用戶自訂需轉換為標籤的屬性，但需重啟 Prometheus 並可能導致時間序列 ID 變更，增加記憶體負擔。正進行 UX 研究，探討如何更有效地處理資源屬性，並計畫整合 OpenTelemetry 的 Entities 提案以區分 Kubernetes、容器等屬性。

實際的應用案例或實作步驟

配置 OpenTelemetry Collector：設定 Prometheus Remote Write 接收器，並啟用 UTF-8 轉換與 Delta 處理器，確保資料格式符合 Prometheus 要求。
Prometheus 配置調整：啟用 promote resource attributes 選項，將資源屬性轉換為標籤，並監控 Delta 轉換處理器的狀態。
遠端寫入協議整合：在 Prometheus 中配置 Remote Write v2，支援原生直方圖與 Exemplars，並啟用寫入統計資訊。

該技術的優勢與挑戰

優勢：

Prometheus 的拉取式模型與 OpenTelemetry 的推送式模型可透過遠端寫入協議整合，實現靈活的監控架構。
UTF-8 支援與 Delta 轉換處理器提升資料處理的準確性與效率。
原生直方圖與 Exemplars 支援提升監控細粒度與追蹤能力。

挑戰：

資源屬性轉換需重啟 Prometheus，可能導致時間序列 ID 變更與記憶體負擔增加。
Delta 轉換處理器需維護狀態，可能影響查詢效能。
高基數資源屬性（如 200 個以上）需優化存儲與查詢效能，例如透過 Parquet 檔案處理。

總結

Prometheus 與 OpenTelemetry 的互操作性透過遠端寫入協議、資料轉換處理器與資源屬性整合，逐步實現高效監控架構。未來需進一步優化 UTF-8 支援、Delta 轉換查詢效能，並整合 OpenTelemetry 的 Entities 設計以提升資源屬性處理的語境感知能力。建議用戶根據實際需求選擇合適的監控模型，並透過 OpenTelemetry Collector 進行資料轉換與導出，以實現靈活的雲原生監控方案。