Prometheus 監控告警實戰 2026：PromQL、Alertmanager 與 SLO 驅動的可觀測性

為什麼 Prometheus 仍是雲原生監控的事實標準

在 OpenTelemetry 蓬勃發展的 2026 年，Prometheus 依然主導指標（Metrics）領域。它以拉取模型（Pull） + 多維資料模型 + 強大 PromQL 著稱，配合 Alertmanager 形成閉環告警。理解它的設計取捨，是搭建可靠可觀測性的第一步。

維度	Prometheus	推模型（Push）方案
採集	主動拉取 /metrics	客戶端主動推送
查詢	PromQL 多維靈活	依賴外部儲存查詢
服務發現	原生支援 K8s/Consul	需自行實作
適用	機器/服務指標	短生命週期任務（配 Pushgateway）

---

架構與核心元件

• Prometheus Server：抓取、儲存（本地 TSDB）、執行 PromQL。
• Exporter：把第三方系統指標暴露為 /metrics（node_exporter、blackbox_exporter 等）。
• Alertmanager：去重、分組、路由、靜默告警。
• Pushgateway：承接批次/短任務的推送指標。

# prometheus.yml 最小配置
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["node-1:9100", "node-2:9100"]
  - job_name: "api"
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_name]
        regex: "order-api"
        action: keep

排障抓取失敗時，可用 HTTP 狀態碼 工具對照 Exporter 回傳的回應碼（如 200/503），快速定位是採集端還是暴露端問題。

---

PromQL 核心函數

rate / irate：計算速率

# 每秒 HTTP 請求數（5m 視窗，自動去毛刺）
rate(http_requests_total[5m])

# 瞬時速率（最近兩個樣本），更靈敏但更易抖
irate(http_requests_total[5m])

histogram_quantile：分位延遲

http_request_duration_seconds_bucket 是直方圖指標，用分位函數看 P99 延遲：

# P99 請求延遲
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

標籤聚合

# 按服務與狀態碼彙總 QPS
sum by (service, code) (rate(http_requests_total[5m]))

---

記錄規則（Recording Rules）：預計算降本

把高頻、昂貴的查詢預計算為新時間序列，儀表盤直接讀結果。

# rules/recording.yml
groups:
  - name: http_slo
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))
      - record: job:request_latency:p99
        expr: |
          histogram_quantile(0.99,
            sum by (job, le) (rate(http_request_duration_seconds_bucket[5m])))

---

告警規則與 Alertmanager

告警規則

# rules/alerts.yml
groups:
  - name: availability
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m                 # 持續 10 分鐘才觸發，避免抖動
        labels:
          severity: critical
        annotations:
          summary: "錯誤率超過 5%"
          description: "服務 {{ $labels.job }} 5xx 錯誤率 {{ $value | humanizePercentage }}"

Alertmanager 路由與分組

# alertmanager.yml
route:
  receiver: "slack-default"
  group_by: ["alertname", "job"]
  group_wait: 30s          # 同組首次等待，聚合多條
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ["severity=critical"]
      receiver: "pagerduty"
      continue: true
    - matchers: ["job=~"batch.*"]
      receiver: "slack-batch"

receivers:
  - name: "slack-default"
    slack_configs:
      - api_url: ${SLACK_URL}
        channel: "#alerts"

抑制（Inhibition）與靜默（Silence）

• 抑制：當「主機宕機」告警存在時，抑制該機上「服務不可用」告警，避免噪音。
• 靜默：維護視窗（如發版）臨時遮蔽特定告警，可用 Cron 說明 工具規劃維護時段。

---

SLO 與錯誤預算燃燒率

用 SLO（服務等級目標）替代「拍腦袋閾值」，是現代告警的核心。以 99.9% 可用性為例：

# 30 天視窗內的合規比（good / total）
(
  sum(rate(http_requests_total{code!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) > 0.999

燃燒率（Burn Rate）告警在錯誤預算快速消耗時提前報警：

- alert: ErrorBudgetBurnFast
  expr: |
    (
      sum(rate(http_requests_total{code=~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))
    ) > (14.4 * (1 - 0.999))   # 1h 內燒光 30d 預算的 14.4 倍速率
  for: 5m
  labels: { severity: critical }

---

應用埋點：別只靠 Exporter

業務指標需要主動埋點。以 Python 為例：

from prometheus_client import Counter, Histogram, start_http_server

REQUESTS = Counter("http_requests_total", "總請求數", ["method", "code"])
LATENCY = Histogram("http_request_duration_seconds", "請求耗時")

start_http_server(8000)   # 暴露 /metrics

@LATENCY.time()
def handle(req):
    REQUESTS.labels(req.method, "200").inc()
    return "ok"

前端或閘道側，可把結構化指標先經 JSON 格式化 工具校驗，再寫入監控管線，避免髒資料汙染查詢。

---

生產最佳實踐清單

1. 合理設 for：避免瞬時抖動產生告警風暴。
2. Cardinality 控制：高基數列（如 user_id）不要做標籤，會撐爆 TSDB。
3. 分層告警：Warning 進群，Critical 進值班（Pager）。
4. 記錄規則前置：儀表盤查詢走預計算。
5. 長期儲存：本地 TSDB 配 Thanos / Mimir 做遠端寫，突破單機保留上限。

---

常見問題 FAQ

Q1：rate 和 irate 怎麼選？

看趨勢用 rate（平滑穩）；看瞬時尖刺用 irate（靈敏）。儀表盤一般用 rate。

Q2：直方圖還是摘要（Summary）？

需要跨實例聚合分位（如全域 P99）用直方圖；單實例且無法預知分位用 Summary。直方圖更靈活，推薦預設。

Q3：告警一直抖動怎麼辦？

給告警規則加 for: 10m，或對指標做更長的 rate 視窗，吸收短時波動。

Q4：label 太多會怎樣？

每個唯一 label 組合都是一條時間序列。濫用高基數列會導致記憶體與寫入爆炸，是 Prometheus 最常見的效能坑。

Q5：Prometheus 能替代日誌和鏈路嗎？

不能。Metrics 看「總量與趨勢」，Logs 看「單條細節」，Traces 看「呼叫路徑」。三者互補，構成完整可觀測性。

---

工具推薦

在 Prometheus 運維中，以下 工具庫 能幫上忙：

• HTTP 狀態碼 — 對照 Exporter/Alertmanager 介面回應
• Cron 說明 — 規劃維護靜默視窗與採集週期
• JSON 格式化 — 校驗告警 Webhook 與指標負載

---

Prometheus 的威力不在「能畫圖」，而在「用 PromQL 把業務健康翻譯成可量化的 SLO，再用 Alertmanager 把噪音過濾成可行動的告警」。把指標、告警、SLO 三層串起來，監控才真正有價值。