跳至主要内容

Prometheus 概念摘要（從圖像筆記整理）

一句話​

Prometheus 是用來收集、儲存、查詢與告警時間序列指標的開源系統，核心採 pull-based scrape。

1) 為什麼需要 Prometheus​

  • 早期監控常見問題：工具分散、查詢不一致、標準化不足。
  • Prometheus 提供統一模型：
    • 指標（metrics）
    • 時間序列（time series）
    • 查詢（PromQL）
    • 告警（Alertmanager）

2) 核心工作方式​

Pull-based（主流）​

  • Prometheus 週期性去目標服務抓取 /metrics（scrape）。
  • scrape_config 決定抓誰、多久抓一次。

Push-based（例外）​

  • 針對短生命週期工作（如 batch job）可先推到 Pushgateway。
  • 最終仍由 Prometheus 去抓 Pushgateway。

指標可被抓取的前提​

  1. 指標格式符合 OpenMetrics / Prometheus exposition format。
  2. 可由 Prometheus 到達指定 endpoint。

3) 在 Kubernetes 的常見做法​

  • 常用 Prometheus Operator。
  • 以 ServiceMonitor（CRD）宣告抓取目標。
  • Operator 依 ServiceMonitor 生成/更新 scrape 設定。

4) 常見架構選項​

  1. Standalone Prometheus：小規模、單體部署。
  2. Federation：多個 Prometheus 分層聚合。
  3. Thanos：多實例聚合 + 長期儲存 + 全域查詢。

5) 生態系​

  • Prometheus：收集與查詢核心。
  • Alertmanager：告警路由、抑制、分派（Slack/PagerDuty/Webhook）。
  • Grafana：可視化儀表板。
  • Exporters：把各系統暴露為 Prometheus 可抓格式。
  • Thanos Ruler / Query：跨叢集規則與查詢（若採 Thanos）。

6) 告警流程​

  1. Prometheus 規則判斷異常（如記憶體 > 80%）。
  2. Prometheus 送告警給 Alertmanager。
  3. Alertmanager 依路由/分組策略通知外部系統。

7) 常見 metric 類型​

  1. Counter：單調遞增。
  2. Gauge：可升可降。
  3. Histogram：桶化分布（可算分位數）。
  4. Summary：流式分位數/總量統計。

8) 查詢與運維重點​

  • 常用函數：rate, irate, sum, max, min。
  • 高 cardinality 會拖垮查詢與成本。
  • 用 relabel 設定控制 labels，避免無限維度膨脹。

9) 給 SRE 的實務結論​

  • 先定義 SLI/SLO，再反推要收的 metrics。
  • 優先監控四訊號：延遲、流量、錯誤、飽和度。
  • 從「能告警 + 能行動」的最小儀表板開始，不追求一次到位。