對於剛接觸監控系統的工程師來說，最頭痛的往往不是如何收集數據，而是面對各種不同的工具與格式。在過去，如果你想將應用程式的指標傳送到 Amazon CloudWatch，通常需要經過複雜的轉換過程，或者依賴特定的 SDK。而 AWS 最近推出的 OpenTelemetry 指標支持，正是為了打破這種碎片化。
首先我們要理解什麼是 OpenTelemetry。簡單來說，OpenTelemetry 是一個開源的標準框架，旨在統一可觀測性 Observability 的三根支柱：指標 Metrics、日誌 Logs 以及追蹤 Traces。它定義了一套通用的協議 OTLP，讓開發者可以用同一套標準來收集數據，而不需要為了換一個監控後端就重寫所有程式碼。
這次更新的核心在於 CloudWatch 現在能原生接收 OTLP 格式的指標。這意味著你的應用程式可以直接將指標發送到 CloudWatch，而不需要在中間架設繁瑣的轉換管線。對於團隊來說，這解決了供應商鎖定 Vendor Lock-in 的問題，讓數據在不同平台之間的遷移變得更加簡單。
針對指標管理，這次更新引入了一個關鍵概念叫做高基數 High Cardinality 存儲。在監控領域，基數指的是指標標籤 Label 的唯一值數量。例如，如果你為每個使用者 ID 設置一個標籤，當使用者達到數百萬個時，基數就會變得極高。傳統的監控系統在處理高基數數據時容易崩潰或導致成本飆升。CloudWatch 現在支持單個指標最多 150 個標籤，讓工程師能記錄更豐富的上下文資訊，而不需要為了性能而刪減數據。
此外，AWS 將 Prometheus 的查詢語言 PromQL 整合進了 CloudWatch。Prometheus 是目前雲原生環境中最主流的監控工具，而 PromQL 是其強大的查詢語言。讓 CloudWatch 支持 PromQL，意味著原本習慣使用 Prometheus 或 Grafana 的工程師，不需要重新學習一套新的查詢語法，就能直接在 CloudWatch 控制台分析數據並建立告警。
在實務運作上，最令人驚艷的是自動化的資源上下文豐富化。當指標進入 CloudWatch 時，AWS 會自動幫你加上帳號 ID、區域 Region、叢集 ARN 以及資源標籤。這解決了在大型分散式系統中，很難快速將某個指標對應到具體哪個 AWS 資源的痛點。
然而，在追求便利的同時，資深工程師會提醒你注意成本。雖然目前處於預覽階段且免費，但高基數指標在正式收費後可能會產生巨大的費用。如果你在每個微服務中都發送大量詳細的標籤，而沒有適當的過濾策略，最終的帳單可能會讓財務部門感到震驚。
總結來說，這次更新讓 CloudWatch 完成了對 OpenTelemetry 三大支柱的全方位支持。對於開發者而言，這簡化了基礎設施的部署，讓監控從 碎片化的工具組合 轉向 統一的標準協議。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。