熱線電話：400-882-3320
較適合維持現有組合
- 規模與保留期可控，Instance 運作穩定
- 平台團隊負責 PromQL、Rule、容量及升級
- 主要工作是 Metrics 查詢與視覺化
Prometheus + Grafana 共存指引
Prometheus 與 Grafana 替代方案：保留 Metrics 資產，驗證缺少的脈絡
協助已使用 Prometheus 收集、Grafana 分析的團隊，驗證 Remote Write、長期儲存、Label、Alert 同等性，以及日誌、Trace、Kubernetes 的關聯。
本文由評估選項之一的觀測雲發布。結論只建基於截至 2026-08-17 的官方公開文件；本文未進行相同工作負載的跨產品效能或價格測試。
範圍備註： 本文不假設託管平台必然較佳，也不比較未以相同工作負載驗證的成本或效能。
- Prometheus Remote Write
- PromQL 與 Label
- Grafana Dashboard
- 日誌、Trace 與 Event
以真實 Kubernetes 事故驗證 Metrics、日誌、Trace 及 Event 是否形成證據鏈。
直接結論
Prometheus 及 Grafana 通常應先共存驗證，而非一次替換
保留現有 Exporter、PromQL、Rule、Dashboard 及 Alert，同時把受控的 Metrics 範圍經 Remote Write 送往第二條路徑。以原路徑為基準，驗證長期儲存、Label 管治，以及由 Metrics 前往日誌、Trace、Kubernetes、Release 及使用者影響的調查。
值得評估統一分析
- 多個 Cluster 及 Team 令 Label、Rule、權限、容量難以管治
- Metrics Alert 後仍要切換日誌、Trace 及 Cloud Console
- 長期儲存、Incident 協作、RUM 或業務影響是明確缺口
評估準則
測試第二條路徑前，先記錄現有 Metrics Stack
盤點 Prometheus Instance、Exporter、ServiceMonitor、Recording Rule 及 Alerting Rule
量度 Active Series、Cardinality、Scrape Interval、保留、Query Peak 及長期儲存要求
記錄 Grafana Data Source、Dashboard、Variable、Plugin、權限及通知依賴
測試 Remote Write Queue、Retry、Filter、認證、TLS 及跨區域 Network Cost
以相同 Alert 比較前往日誌、Trace、Pod、Release 及使用者影響的路徑
決策矩陣
以相同責任比較自建與 Remote Write 共存
在較小螢幕可橫向捲動此表格。
決策範圍
維持 Prometheus + Grafana
Remote Write 至觀測雲
收集資產
保留 Exporter、Scrape 設定、PromQL 及 Rule
Prometheus 繼續收集，只傳送選定 Series
儲存責任
自行運行 Local TSDB 及任何 Remote Component
使用公開服務邊界，團隊仍管治傳送範圍及 Label
查詢體驗
保留 Grafana Data Source、Explore、Dashboard 及 Alert
驗證 Metrics 能否在共用 Object 脈絡連接其他遙測
遷移風險
沒有切換，但現有架構複雜度仍然存在
同等與回滾準則通過前保留原 Query 及 Alert
先保護正在運作的 Prometheus 與 Grafana 資產
Prometheus 分開說明 Local Storage 與 Remote Integration；Grafana 則將 Data Source 定義為查詢、視覺化及 Alert 的入口。提出變更前，先記錄所有依賴。
- 保留 Exporter、PromQL、Recording Rule 及 Alert
- 匯出仍有價值的 Dashboard、Variable、Plugin 及權限
- 只處理已證實的容量、管治或脈絡缺口
把 Remote Write 當作生產 Pipeline 觀察
Remote Write 由 WAL 讀取 Sample，經 Queue 送往 Receiver。PoC 不應只確認圖表出現，還要監察 Backlog、Retry、Throughput、Filter 及時間一致性。
- 由一個 Instance、Cluster 或 Namespace 開始
- 限制首批 Metrics 及 Label 範圍以控制 Cardinality
- 比較 Sample、Timestamp、Label、PromQL 及 Alert
只有事故調查變短，才擴大範圍
由 Latency、Error Rate 或 Resource Alert 開始，確認能否到達 Service Trace、相關日誌、Pod Event、Deployment 及使用者體驗。新介面本身不足以支持遷移。
- 重播一個 Kubernetes 或 Application 事故
- 計算複製 Label、Timestamp 及切換工具次數
- 把 Incident 協作、Review 及權限納入驗收
遷移路徑
先雙寫受控 Metrics，再以真實事故決定
- 匯出 Instance、Rule、Cardinality、保留及 Grafana 依賴
- 為低風險範圍啟用 Remote Write，保留原路徑
- 比較 Series、Label、Timestamp、PromQL 及 Alert
- 重播真實事故並前往日誌、Trace、Kubernetes 及 Release
- 按停止、回滾及擴大準則作出決定
常見問題
選型與遷移常見問題
觀測雲會替代 Prometheus Exporter 嗎？
不一定。現有 Exporter 及 Prometheus 可繼續收集，再把選定 Metrics 經 Remote Write 傳送至 DataKit。是否調整收集方式應由營運責任與資料管治決定。
接入觀測雲後仍需要 Grafana 嗎？
可保留有價值的 Dashboard 及團隊習慣。PoC 應先驗證 Metrics 是否更自然地連接日誌、Trace、Kubernetes、RUM 及 Event。
Remote Write 雙寫需要監察甚麼？
需要監察 Pending Sample、Retry、Network、Filter、Cardinality、Timestamp、Query 及 Alert 同等性，並保留原 Prometheus 作為回滾路徑。
可否直接把 Remote Write 2.0 當成生產前提？
不可以。Prometheus 目前將 2.0 標示為 Experimental，必須逐一確認 Sender、Receiver 及 Version 支援。
下一步
以現有 Prometheus 架構設計共存 PoC
準備 Instance、Active Series、Rule、Dashboard、保留、主要 Alert 及真實事故，一起訂立驗證及回滾準則。