Talk Summary

Prometheus Monitoring Stack 很方便易用，但隨著組職對於監控的廣度和深度要求越來越高，伴隨著 Metric 在量與質的不斷提升之下，使用網路範例快速部署的 Prometheus 已經開始為人詬病，如何架設與管理一個兼具效能與高可用的監控系統變成為一個嚴肅的課題，所以此分享介紹如何透過整合 Thanos 來有效率地搜尋與儲存大量的 Prometheus Metrics 資料，並且導入 Prometheus Federation 來梳整大量 K8s 叢集所產生的 Metric，讓 Prometheus 成為 SRE 最可靠的夥伴。

涵蓋主題

Prometheus 架構演進 — 從單機到高可用的監控架構設計
Thanos 解決方案 — 六大核心組件與無限寶石類比
Federation 實踐 — 官方 Federation vs Thanos Remote Write 比較
實務經驗 — 儲存成本估算、Downsampling、去重與警報優化

Prometheus 的核心挑戰

缺乏全域視角 — 無法在單一介面查詢多個 Cluster 的 Metrics 資料。在多叢集環境下，維運人員必須切換多個 Datasource 才能排除問題，效率極低
高可用性 (HA) 難題 — 單一 Prometheus 難以實現穩定的 HA
Scrape 週期不一致 — 多個 Prometheus 同時 Scrape 可能導致資料點時間不一致，影響圖表呈現。Grafana 建議開啟 sessionAffinity 以確保圖表呈現的一致性
單一節點負載瓶頸 — 當 Metrics 量過大時，單一 Prometheus 的處理能力會遇到瓶頸
儲存成本高昂 — 使用 SSD/HDD 儲存大量長期 Metrics 資料非常昂貴。以 400 kb/s 流量估算，一個月的資料量接近 1 TB；在 AWS Tokyo 使用 EBS gp2，單一叢集每月約需 USD $118.8，叢集越多成本越驚人

Thanos 解決方案

一組可組合成具有高可用性、無限儲存容量的監控系統組件，能無縫整合至現有的 Prometheus。

六大核心組件（無限寶石類比）

Sidecar（力量寶石） — 持續將 Metrics 送往物件儲存 (Object Storage)
Compactor + Store（空間寶石） — Compactor 整理與降採樣資料以加速查詢；Store 作為物件儲存資料的存取網關。查詢長達一年的資料時不需要 15 秒級的高精度資料，降採樣為 5 分鐘或 1 小時解析度可大幅提升查詢速度
Query（靈魂寶石） — Thanos 核心，提供全域視角 (Global View) 並負責去重 (Deduplication)。當 HA 部署兩套 Prometheus 抓取相同資料時，會根據標籤將重複數列合併成一條
Query Frontend（時間寶石） — 透過快取 (Caching) 與查詢分割 (Splitting) 加速查詢結果
Receive（心靈寶石） — 接收其他 Prometheus 的 Remote Write Metrics，實現即時查詢
Rule（現實寶石） — 管理跨叢集的警報規則與錄製規則

Federation 實踐比較

方案	優點	缺點
官方 Federation	架構簡單	精準度損失（Scrape 時間戳記 ≠ 原始資料時間）
Thanos Remote Write	精準度高（時間戳記一致）	需依賴 Thanos 組件

架構改進成效

集中管理的好處

統一全域查詢，單一 Grafana 資料源
統一警報管理（Alertmanager N → 1）
物件儲存比硬碟便宜，受控叢集不需跑完整 Thanos/Alertmanager Stack

遷移注意事項

現有圖表需增加 kubernetesCluster 標籤過濾，才能正確顯示各叢集資料
警報需從 sum(...) 改為 sum by (kubernetesCluster)(...) 以區分各叢集狀況，避免因資料加總導致誤報

A Tale of Prometheus Monitoring Evolution

🖥️ 投影片