觀點 · 資訊分享

CloudWatch 原生支援 OpenTelemetry 指標與 PromQL：按 GB 計費，內含 15 個月儲存

AWS CloudWatch 現在能直接收 OpenTelemetry（OTLP）格式的指標，並用 Prometheus 的 PromQL 查詢。計費採每 GB 寫入量，15 個月儲存已包含在內。

一句話看懂：AWS CloudWatch 現在能直接收 OpenTelemetry 格式的指標，並用 PromQL 查詢，計費改成依寫入量（每 GB），15 個月儲存已包含在內。

CloudWatch 原生支援 OTel 指標資訊圖卡：用 OTLP 寫入、PromQL 查詢，自訂與 AWS 指標一起看

先用白話講：這在解決什麼？

想像你家有一台體重計、一台血壓計、一台體溫計，每台各用各的 App 記錄。想知道「這週整體健康狀況」，得開三個 App 自己對照。

系統監控也有同樣的麻煩：應用程式自己的指標（例如每秒訂單數）常放在一個地方，AWS 服務產生的指標（例如 EC2 的 CPU）放在另一個地方。這次更新，是讓 CloudWatch 直接接收前者，並讓兩者放在同一處查詢。

AWS 在 2026 年 6 月 16 日宣布，Amazon CloudWatch 原生支援 OpenTelemetry 指標：

這張表只整理公告提到的差異，沒有說的細節（例如與舊有 CloudWatch 指標的價格比較），我就不推測。

CloudWatch 提供相容 Prometheus 的查詢 API，已經在用 OpenTelemetry、Prometheus 或 Grafana 的團隊，可以把 CloudWatch 當成一個目的地接進現有工具
區域：所有商用 AWS 區域，但不包含中東（阿聯）、中東（巴林）與以色列（特拉維夫）
價格以 CloudWatch 定價頁為準；公告沒有列出每 GB 的實際金額
入門：照 CloudWatch 指標文件設定，把 OpenTelemetry Collector 的輸出指向 CloudWatch

我自己的專案不算大，監控多半是看主機的基本指標加上應用程式的 log。但如果哪天客戶要求更完整的觀測，能「用已有的 OpenTelemetry 設定、直接送進 AWS 原生服務」會省很多事，不必另外維護一套 Prometheus。

不過「每 GB 計費」要小心：指標量如果沒控制（例如標籤太多、取樣太密），帳單可能比預期高。建議先用小範圍測試，看實際寫入量，再決定要不要全面搬過來。

OpenTelemetry 是什麼？

一套開放的觀測標準，讓程式用統一格式送出指標、日誌與追蹤資料，OTLP 就是它的傳輸協定。

PromQL 是什麼？

Prometheus 使用的查詢語言，常用來查詢與計算監控指標，Grafana 也常搭配它畫圖表。

哪些區域可以用？

官方說除了中東（阿拉伯聯合大公國）、中東（巴林）與以色列（特拉維夫）之外，所有商用 AWS 區域都能用。價格細節要看 CloudWatch 定價頁，這則公告沒有列出數字。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。