Prometheus告警處理

在Prometheus Server中定義告警規則以及產生告警，Alertmanager組件則用於處理這些由Prometheus產生的告警。Alertmanager即Prometheus體系中告警的統一處理中心。

Prometheus告警簡介

告警能力在Prometheus的架構中被划分成兩個獨立的部分。
如下所示，通過在Prometheus中定義AlertRule（告警規則），Prometheus會周期性的對告警規則進行計算，如果滿足告警觸發條件就會向Alertmanager發送告警信息。

在Prometheus中一條告警規則主要由以下幾部分組成：

• 告警名稱：用戶需要為告警規則命名，當然對於命名而言，需要能夠直接表達出該告警的主要內容
• 告警規則：告警規則實際上主要由PromQL進行定義，其實際意義是當表達式（PromQL）查詢結果持續多長時間（During）后出發告警

在Prometheus中，還可以通過Group（告警組）對一組相關的告警進行統一定義。當然這些定義都是通過YAML文件來統一管理的。

Alertmanager作為一個獨立的組件，負責接收並處理來自Prometheus Server(也可以是其它的客戶端程序)的告警信息。
Alertmanager可以對這些告警信息進行進一步的處理，比如當接收到大量重復告警時能夠消除重復的告警信息，同時對告警信息進行分組並且路由到正確的通知方，Prometheus內置了對郵件，Slack等多種通知方式的支持，同時還支持與Webhook的集成，以支持更多定制化的場景。同時AlertManager還提供了靜默和告警抑制機制來對告警通知行為進行優化。

Alertmanager特性

Alertmanager除了提供基本的告警通知能力以外，還主要提供了如：分組、抑制以及靜默等告警特性：

分組

分組機制可以將詳細的告警信息合並成一個通知。在某些情況下，比如由於系統宕機導致大量的告警被同時觸發，在這種情況下分組機制可以將這些被觸發的告警合並為一個告警通知，避免一次性接受大量的告警通知，而無法對問題進行快速定位。

例如，當集群中有數百個正在運行的服務實例，並且為每一個實例設置了告警規則。假如此時發生了網絡故障，可能導致大量的服務實例無法連接到數據庫，結果就會有數百個告警被發送到Alertmanager。

而作為用戶，可能只希望能夠在一個通知中中就能查看哪些服務實例收到影響。這時可以按照服務所在集群或者告警名稱對告警進行分組，而將這些告警內聚在一起成為一個通知。

告警分組，告警時間，以及告警的接受方式可以通過Alertmanager的配置文件進行配置

抑制

抑制是指當某一告警發出后，可以停止重復發送由此告警引發的其它告警的機制。

例如，當集群不可訪問時觸發了一次告警，通過配置Alertmanager可以忽略與該集群有關的其它所有告警。這樣可以避免接收到大量與實際問題無關的告警通知。

抑制機制同樣通過Alertmanager的配置文件進行設置。

靜默

靜默提供了一個簡單的機制可以快速根據標簽對告警進行靜默處理。如果接收到的告警符合靜默的配置，Alertmanager則不會發送告警通知。
靜默設置需要在Alertmanager的Web頁面上進行設置。

自定義Prometheus告警規則

Prometheus中的告警規則允許你基於PromQL表達式定義告警觸發條件，Prometheus后端對這些觸發規則進行周期性計算，當滿足觸發條件后則會觸發告警通知。
默認情況下，用戶可以通過Prometheus的Web界面查看這些告警規則以及告警的觸發狀態。
當Promthues與Alertmanager關聯之后，可以將告警發送到外部服務如Alertmanager中並通過Alertmanager可以對這些告警進行進一步的處理。

定義告警規則

一條典型的告警規則如下所示：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency
      description: description info

在告警規則文件中，我們可以將一組相關的規則設置定義在一個group下。在每一個group中我們可以定義多個告警規則(rule)。一條告警規則主要由以下幾部分組成：

• alert：告警規則的名稱。
• expr：基於PromQL表達式告警觸發條件，用於計算是否有時間序列滿足該條件。
• for：評估等待時間，可選參數。用於表示只有當觸發條件持續一段時間后才發送告警。在等待期間新產生告警的狀態為pending。
• labels：自定義標簽，允許用戶指定要附加到告警上的一組附加標簽。
• annotations：用於指定一組附加信息，比如用於描述告警詳細信息的文字等，annotations的內容在告警產生時會一同作為參數發送到Alertmanager。

為了能夠讓Prometheus能夠啟用定義的告警規則，我們需要在Prometheus全局配置文件中通過rule_files指定一組告警規則文件的訪問路徑，Prometheus啟動后會自動掃描這些路徑下規則文件中定義的內容，並且根據這些規則計算是否向外部發送通知：

rule_files:
  [ - <filepath_glob> ... ]

默認情況下Prometheus會每分鍾對這些告警規則進行計算，如果用戶想定義自己的告警計算周期，則可以通過 evaluation_interval 來覆蓋默認的計算周期：

global:
  [ evaluation_interval: <duration> | default = 1m ]

模板化

一般來說，在告警規則文件的annotations中使用 summary 描述告警的概要信息， description 用於描述告警的詳細信息。
同時Alertmanager的UI也會根據這兩個標簽值，顯示告警信息。為了讓告警信息具有更好的可讀性，Prometheus支持模板化label和annotations的中標簽的值。

通過 $labels.<labelname> 變量可以訪問當前告警實例中指定標簽的值。$value則可以獲取當前PromQL表達式計算的樣本值。

# To insert a firing element's label values:
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通過模板化優化summary以及description的內容的可讀性：

groups:
- name: example
  rules:
  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

查看告警狀態

用戶可以通過Prometheus WEB界面中的Alerts菜單查看當前Prometheus下的所有告警規則，以及其當前所處的活動狀態。
同時對於已經pending或者firing的告警，Prometheus也會將它們存儲到時間序列ALERTS{}中。
可以通過表達式，查詢告警實例：

ALERTS{alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}

樣本值為1表示當前告警處於活動狀態（pending或者firing），當告警從活動狀態轉換為非活動狀態時，樣本值則為0。

實例：定義主機監控告警

修改Prometheus配置文件prometheus.yml,添加以下配置：

rule_files:
  - /etc/prometheus/rules/*.rules # 路徑根據實際情況而定

在目錄/etc/prometheus/rules/下創建告警文件hoststats-alert.rules內容如下：
隨着版本更新，有些字段名稱發生變化了，可以先在Graph頁面執行，調試命令，有輸出結果后再寫入到rules文件中，具體參數可以看node主機的metrics中顯示的信息

groups:
- name: hostStatsAlert
  rules:
  - alert: hostCpuUsageAlert
    expr: sum by(instance) (avg without(cpu) (irate(node_cpu_seconds_total{mode!="idle"}[5m]))) > 0.3 # 可以數值大小根據實際情況而定
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usgae high"
      description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
  - alert: hostMemUsageAlert
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.3 # 數值大小根據實際情況而定
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} MEM usgae high"
      description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"

重啟Prometheus后訪問Prometheus UI http://127.0.0.1:9090/rules可以查看當前以加載的規則文件。

切換到Alerts標簽http://127.0.0.1:9090/alerts可以查看當前告警的活動狀態。

此時，我們可以手動拉高系統的CPU使用率，驗證Prometheus的告警流程，在主機上運行以下命令：

cat /dev/zero>/dev/null

運行命令后查看CPU使用率情況，如下圖所示：

Prometheus首次檢測到滿足觸發條件后，hostCpuUsageAlert顯示由一條告警處於活動狀態。由於告警規則中設置了1m的等待時間，當前告警狀態為PENDING，如果1分鍾后告警條件持續滿足，則會實際觸發告警並且告警狀態為FIRING，如下圖所示：