在建構現代化的監控系統時，準確與及時的告警機制扮演著關鍵角色。本文將探討如何在 Prometheus 中設定有效的告警規則，並整合 AlertManager 實作智慧化的告警管理。

告警規則的基本結構

一個完整的 Prometheus 告警規則通常包含以下幾個主要部分：

告警條件（Expression）：使用 PromQL 定義告警觸發的條件
時間引數（For）：設定條件持續時間
標籤（Labels）：用於分類別和識別告警
註解（Annotations）：提供告警的詳細說明

讓我們以一個監控 CPU 使用率的告警規則為例：

- alert: HighCPUUsage
  expr: rate(node_cpu_seconds_total{mode="idle"}[5m]) < 0.1
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "CPU 使用率過高"
    description: "CPU 使用率已經超過 90%，請檢查相關應用程式或服務。"

在這個例子中，每個元件都有其特定的功能：

告警條件：使用 rate() 函式運算 CPU 閒置時間的變化率，當空閒時間低於 10% 時觸發告警
持續時間：設定為 2 分鐘，避免短暫的負載尖峰造成誤報
嚴重性標籤：標記為 critical，方便後續的告警處理流程
告警說明：提供簡潔的問題描述和建議處理方向

告警時間引數的最佳化設定

適當的時間引數設定對於避免告警風暴至關重要。以下是幾個關鍵的時間引數：

1. For 引數

for 引數用於設定告警條件必須持續滿足的時間。例如：

for: 5m   # 條件需持續 5 分鐘才觸發告警

2. 評估間隔

在 Prometheus 的全域設定中設定：

evaluation_interval: 30s   # 每 30 秒評估一次告警規則

3. AlertManager 的分組等待時間

route:
  group_wait: 30s         # 等待 30 秒後傳送第一次告警
  group_interval: 5m      # 同組後續告警的最小間隔
  repeat_interval: 4h     # 重複告警的間隔時間

AlertManager 設定與通知整合

AlertManager 負責處理來自 Prometheus 的告警，並根據設定將告警傳送至不同的通知管道。

基本設定結構

一個標準的 AlertManager 設定包含：

route:
  receiver: 'slack'
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 1h

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXXXXXXXX/XXXXXXXXX/xxxxxxxxxxxxxxxxxxxxxxxxxxx'
        channel: '#alerts'
        send_resolved: true

這個設定實作了：

告警分組與等待機制
透過 Slack 傳送告警通知
告警解除時自動傳送還原通知

告警規則的最佳實踐

在實際應用中，玄貓建議遵循以下最佳實踐：

合理的閾值設定：根據系統實際情況設定適當的告警閾值
適當的延遲時間：為不同類別的指標設定合適的 for 時間
清晰的告警描述：在 annotations 中提供詳細與易懂的問題描述
告警分級管理：使用 labels 對告警進行分級和分類別
避免告警風暴：合理使用分組和抑制規則

在監控系統的實際營運中，告警規則的設定需要不斷調整和最佳化。透過持續觀察和改進，我們可以建立一個既能及時發現問題，又不會造成過多幹擾的告警系統。告警系統的最終目標是幫助維運團隊快速發現和解決問題，而不是成為額外的負擔。 expr: rate(node_cpu_seconds_total{mode=“idle”}[5m]) < 0.1 # 告警表示式 for: 2m # 持續時間 labels: severity: critical # 告警嚴重程度 annotations: summary: “CPU 使用率過高” # 告警摘要 description: “CPU 使用率已經超過 90%，請檢查相關應用程式或服務。” # 詳細描述 __CODE_BLOCK_5__promql

CPU 使用率

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode=“idle”}[5m])) * 100)

記憶體使用率

(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

硬碟使用率

100 - ((node_filesystem_avail_bytes{mountpoint="/"} * 100) / node_filesystem_size_bytes{mountpoint="/"}) __CODE_BLOCK_6__promql

計算 HTTP 請求速率

rate(http_requests_total[5m]) __CODE_BLOCK_7__promql

計算所有例項的平均值

avg(rate(http_requests_total[5m])) by (job) __CODE_BLOCK_8__promql

選擇最近 5 分鐘的資料

process_cpu_seconds_total[5m] __CODE_BLOCK_9__yaml groups:

name: resource-monitoring rules:
- alert: HighCPUUsage expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode=“idle”}[5m])) * 100) > 85 for: 5m labels: severity: warning annotations: summary: “CPU 使用率警告” description: “例項 {{ $labels.instance }} CPU 使用率超過 85%”
- alert: CriticalCPUUsage expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode=“idle”}[5m])) * 100) > 95 for: 2m labels: severity: critical annotations: summary: “CPU 使用率嚴重警告” description: “例項 {{ $labels.instance }} CPU 使用率超過 95%”


### 2. 分層警示策略

```yaml
groups:
- name: memory-alerts
  rules:
  - alert: MemoryWarning
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 80
    for: 10m
    labels:
      severity: warning
      team: infrastructure
    annotations:
      summary: "記憶體使用率警告"
      description: "記憶體使用率超過 80%"

  - alert: MemoryCritical
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
    for: 5m
    labels:
      severity: critical
      team: infrastructure
    annotations:
      summary: "記憶體使用率嚴重警告"
      description: "記憶體使用率超過 90%，系統可能面臨風險"

3. 避免警示風暴

groups:
- name: disk-alerts
  rules:
  - alert: DiskSpaceWarning
    expr: |
      (
        100 - (
          (node_filesystem_avail_bytes{mountpoint="/"} * 100) / 
          node_filesystem_size_bytes{mountpoint="/"}
        )
      ) > 85
    for: 30m  # 較長的等待時間避免頻繁觸發
    labels:
      severity: warning
    annotations:
      summary: "磁碟空間警告"
      description: "磁碟使用率超過 85%，請及時清理"

記錄規則與告警通知設定

在設定 Prometheus 記錄規則時，正確的設定可以幫助我們更有效地監控系統狀態。讓玄貓為大家深入解析記錄規則的關鍵組成部分：

記錄規則設定的基本結構

groups:
- name: example-recording-group   # 規則群組名稱
  rules:
  - record: job:http_requests:rate5m  # 新時間序列名稱
    expr: rate(http_requests_total[5m])  # PromQL 表示式

每個規則包含以下重要元素：

groups - 用於組織和管理相關的記錄規則
name - 為規則群組提供唯一識別名稱
rules - 包含具體的記錄規則定義
record - 指定新生成的時間序列名稱
expr - 定義計算邏輯的 PromQL 表示式

告警通知系統整合

route:
  receiver: 'slack'
  routes:
  - match:
      severity: 'critical'
    receiver: 'pagerduty'

receivers:
- name: 'slack'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/YOUR-WEBHOOK-URL'
    channel: '#alerts'
    send_resolved: true

- name: 'pagerduty'
  pagerduty_configs:
  - service_key: 'YOUR-PAGERDUTY-KEY'

在告警通知設定中需要注意：

接收器名稱必須一致 - route.receiver 與 receivers.name 需完全比對
Webhook URL 必須有效 - 確保 api_url 為有效的 Slack Webhook 地址
頻道設定要正確 - channel 必須是實際存在的 Slack 頻道
解決通知設定 - send_resolved 決定是否傳送告警解除通知

RabbitMQ 監控例項

groups:
- name: rabbitmq-monitoring
  rules:
  - record: job:rabbitmq_messages:rate5m
    expr: rate(rabbitmq_queue_messages_delivered_total[5m])
  
  - alert: RabbitMQLowDeliveryRate
    expr: sum(job:rabbitmq_messages:rate5m) < 10
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "RabbitMQ 訊息傳遞率過低"
      description: "過去 5 分鐘平均訊息傳遞率低於 10 條/秒"

這個設定展示瞭如何結合記錄規則和告警規則：

首先建立記錄規則計算 RabbitMQ 的訊息傳遞率
根據記錄規則的結果設定告警條件
當傳遞率低於閾值時觸發告警
透過標籤和註解提供告警的詳細資訊

透過這樣的設定，我們可以有效監控 RabbitMQ 的效能，同時透過預先計算的記錄規則降低 Prometheus 的查詢負載。在生產環境中，這種方式可以幫助我們更快速地發現並解決潛在的系統問題。

合理的記錄規則設定能夠顯著提升監控系統的效能，而完善的告警通知設定則確保我們能夠及時接收到重要的系統狀態變化。這兩者的結合為系統的穩定執行提供了強有力的保障。

在現代微服務架構中，建立一個完善的監控預警系統至關重要。本文將探討如何最佳化 Prometheus 與 AlertManager 的設定，以及分享一些實務經驗和解決方案。

警示規則最佳化與效能提升

記錄規則的最佳實踐

記錄規則（Recording Rules）是提升 Prometheus 效能的關鍵工具。透過預先計算並儲存常用查詢結果，可以大幅減少系統負載。以下是幾個核心最佳化原則：

預先計算複雜查詢：

groups:
  - name: service_metrics
    interval: 5m
    rules:
      - record: job:request_errors:rate5m
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)

合理設定評估間隔：根據業務需求設定適當的 interval 值，既確保資料時效性，又不會造成過度負擔。
分組管理：將相關的記錄規則歸類別到同一組，便於管理和維護。

效能調校要點

為了獲得最佳監控效果，需要在以下幾個方面進行調校：

抓取間隔（Scrape Interval）設定：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

資源分配：為 Prometheus 分配足夠的 CPU 和記憶體資源，確保穩定執行。
儲存策略：根據實際需求設定資料保留時間，避免佔用過多磁碟空間。

故障排除與延遲最佳化

常見問題診斷

在維運過程中，可能遇到的常見問題及其解決方案：

警示延遲處理：

route:
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 1h

資料抓取失敗：

檢查目標服務的健康狀態
驗證網路連通性
檢查 Prometheus 設定檔案

效能最佳化策略

提升監控系統效能的關鍵策略：

使用記錄規則減少即時運算：

groups:
  - name: performance_rules
    rules:
      - record: instance_cpu_usage
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

最佳化查詢效率：

避免使用過於複雜的 PromQL 查詢
合理使用標籤過濾
控制時間範圍查詢的跨度

AlertManager 進階設定

通知策略最佳化

設計合理的通知策略對於降低警示疲勞至關重要：

receivers:
  - name: 'team-alerts'
    slack_configs:
      - channel: '#alerts'
        send_resolved: true
        title: '{{ .GroupLabels.alertname }}'
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'team-alerts'

警示分級與路由

根據警示的嚴重程度設計不同的處理流程：

routes:
  - match:
      severity: critical
    receiver: pager-duty
    continue: true
  - match:
      severity: warning
    receiver: slack-alerts

監控系統的效能最佳化是一個持續改進的過程。透過合理設定記錄規則、最佳化警示策略、調整系統引數，我們可以建立一個更加高效與可靠的監控預警系統。在實踐中，需要根據實際業務場景不斷調整和最佳化，確保監控系統能夠準確、及時地反映系統狀態，幫助維運團隊快速發現和解決問題。透過本文的探討，我們已經全面瞭解了這項關鍵技術。玄貓希望這些內容能為大家在技術實踐中帶來實質的幫助，也期待未來能持續分享更多深入的技術見解，一同在技術的道路上不斷精進。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

Prometheus 告警規則設定：從基礎到進階