Prometheus + Grafana 替代方案：擴充自建，還是改用託管平台

如果現有 Prometheus 和 Grafana 已經足以支援值班，我不建議只為換一套介面而遷移。指標容量不足，可以先擴充後端；沒有人能持續負責儲存、升級和復原，再考慮託管服務。值得更換整套平台的情況，是日誌、鏈路和資源資料都有，工程師卻仍要在幾個系統裏重建同一次故障的脈絡。

Prometheus 與 Grafana 原本就互補：前者採集、儲存及查詢指標，執行 recording rule 與告警規則；後者連接資料來源，提供探索、儀表板及告警功能。比較 Prometheus + Grafana 替代方案，應先弄清楚受限的是採集、儲存，還是調查流程。只換 Grafana，並不會同時更換指標後端。Prometheus 架構 · Grafana 資料來源

觀測雲編輯部 · 2026 年 10 月 28 日。本文依官方資料討論自建與託管的工程取捨，觀測雲也是候選產品。算式採用明確假設，並非生產壓測或客戶節省結果。

先找出需要改變的那一層

主要問題是長期保留和跨叢集查詢時，可以先看 Thanos、Mimir 或 VictoriaMetrics 等指標後端。既有 exporter、PromQL 和 Grafana 工作方式有機會繼續使用；新增元件的容量、可用性、升級及復原，仍由平台團隊負責。各項目有自己的架構和相容範圍，接收到指標也不會同時補齊日誌、鏈路及使用者體驗。

希望保留 Grafana，又不想繼續運行後端，可以比較 Grafana Cloud 和相應雲端供應商的託管 Prometheus。Grafana Cloud 與自建 LGTM 是兩種交付方式：Loki、Grafana、Tempo、Mimir 可以組成多訊號平台，自建時仍要運行、升級和復原各個元件。Elastic Observability 與觀測雲等較完整的平台，則把選擇進一步帶到跨訊號調查與實際交付範圍。

這些路線改變的是持續要做的工作。Prometheus 採用 Apache 2.0 授權，Grafana OSS 採用 AGPLv3；所選發行版、外掛及附加產品，還要依各自條款處理。能夠自行部署軟體，不代表運行與整合工作可以不計成本。Prometheus 授權 · Grafana 授權

先算序列與採集頻率，再比較單價

高基數會隨資料一起遷移。把請求 ID 或使用者 ID 放進指標標籤，持續增加的是標籤組合形成的時間序列；新後端可以容納更多序列，卻不會替團隊決定哪些組合值得保留。Prometheus 資料模型

用一個簡單假設說明：20 項服務，每項服務有 10 個介面、5 種狀態，每種組合在 8 個 Pod 上都實際產生一項純量指標，就有 20 × 10 × 5 × 8 = 8,000 條序列。每 15 秒採集一次，每分鐘約 32,000 個樣本；改為 60 秒，每分鐘約 8,000 個樣本。序列數相同，樣本量降為四分之一。這只是一項純量指標的穩態算式，未計重啟、序列更替、直方圖或副本。

減少標籤維度會失去相應的切分方式，延長間隔會降低時間解析度。能否接受，要回到實際查詢和告警視窗。調查用不到的維度可以考慮先聚合或過濾；仍須按 Pod 定位問題，就要保留完成這項工作的資料。

Grafana Cloud Metrics 的費用與活躍序列、每分鐘資料點（DPM）有關。其他服務可能採用不同單位，位元組、序列與資料點無法直接互換。先固定採集範圍、頻率、保留時間及查詢需要，再比較託管費用，差額才有意義。Grafana Cloud 指標計費

remote write 接通後，規則與歷史仍有各自的去向

Prometheus server 為每個 remote write 目的地維護傳送佇列，從 WAL 讀取樣本，再以分片傳送給接收端。目的地變慢就會累積待傳資料；本地查得到，不代表遠端已收到。網絡恢復後，傳送能力還要足以追上新增資料，WAL 也不是無限期的離線歸檔。remote write 佇列與復原

這也是保留既有採集端的價值：可以先改變寫入目的地，而不急着替換全部 exporter。已儲存的歷史資料、recording rule、告警規則與 Grafana 儀表板，則是不同資產，須分別選擇保留、匯入或重建的路徑。

HA 副本尤其容易帶來誤判。Grafana Cloud Metrics 預設依 cluster 和 __replica__ 識別、去重 HA Prometheus 資料：同一組副本共用 cluster 值，各副本則有不同識別值。這是接收端的約定，而非 remote write 協定對所有後端的保證。更換接收端時，副本標識、去重方式與實際收到的序列應一起核對。Grafana Cloud HA 接入

觀測雲 DataKit 提供 Prometheus Remote Write 接收器，既有採集路徑可由此延續。欄位映射須提前處理：未覆寫 measurement 等命名設定時，預設會把 go_memstats_heap_objects 拆成 measurement go 與欄位 memstats_heap_objects；keep_exist_metric_name = true 可以保留完整原始欄位名稱。接收到樣本後，原查詢中的名稱和篩選條件仍須與新模型對齊。觀測雲也提供 MetricsQL 查詢入口，相容語法仍要配合實際查詢結果核對。

調查入口能否串起來，取決於資料約定

Grafana 已能連接多種資料來源，Prometheus 資料來源也支援設定 exemplar 到鏈路的跳轉。既有平台若已有合適的日誌與鏈路後端、穩定標識和可用連結，繼續完善它通常比全面遷移更省事。Grafana Prometheus 資料來源設定

平台團隊額外維護的，是服務名稱、環境、時間範圍和權限如何穿過這些系統。錯誤率告警中的 service 能否篩選同一服務的日誌，日誌的 trace_id 能否找到仍在保留期內的 Trace，決定了這條調查路徑是否可用。

觀測雲工作空間可接收指標、日誌、鏈路及 RUM，鏈路詳情也有相應的關聯入口。識別值一致、相關資料已採集且仍可查詢時，工程師可沿平台入口繼續調查，減少自行維護跳轉與多個後端的工作。欄位與保留策略仍由團隊安排；未採集的請求不會因平台統一而補出來。日誌與鏈路關聯

AI 輔助也應落在相同資料路徑。Obsy Agent Teams 能以已設定工具及獲授權資料處理任務，協助工程師推進調查；引用的事件、篩選條件和時間範圍仍應能被覆核。工具入口連通，與已找到可採取行動的根因，是兩項不同結果。Agent Teams 任務

告警資產與持續費用，決定最後要遷移多少

Alertmanager 已有去重、分組、路由、靜默和抑制功能。叢集故障引發下游告警時，可以用抑制減少重複通知；服務歸屬、門檻與路由設定錯誤，換平台後仍要修正。遷移應保留需要行動的告警與處理指引，不能只追求通知數變少。Alertmanager

歷史儀表板也要按用途保留。低頻的災難復原與合規監控，不能只因最近 90 天沒人開啟就刪除。真正遷移的查詢，要保留單位、聚合、缺失資料及時間視窗的含義；告警還須處理評估週期、等待時間與通知路由。

首年成本可以清楚拆開：

首年投入
= 12 ×（平台帳單 + 客戶端採集資源 + 網絡費用 + 仍須承擔的運行成本）
+ 一次性遷移成本
+ 遷移期額外支出

工程時間與現金支出分別列出；並行運行只計超出穩定方案的額外部分，避免重複計算。觀測雲也應按所選版本及實際接入、處理、儲存與運算等項目報價，不能只用一個指標單價代表全部費用。觀測雲企業版計費

指標後端是主要限制，就先擴充指標後端。希望保留 Grafana 並減少後端運行工作，先看相應託管服務。 跨訊號調查與分散系統維護持續耗用團隊時間時，觀測雲這類統一平台才值得作為較大範圍的替代方案比較。遷移到哪一層，由真正能停用的舊元件、保留下來的調查能力及持續費用共同決定。