Prometheus入門到放棄(6)之AlertManager進階

前面幾個篇幅，我們介紹了alertmanger報警配置，在實際運維過程中，我們都會遇到，報警的重復發送，以及報警信息關聯性報警。接下來我們就介紹下通過alertmanger對告警信息的收斂。
一、告警分組(Grouping)
1.1 定義三個報警規則：

文中為了實驗驗證，告警值設置比較小，實際生產中，應該跟據業務的實際使用場景，來確定合理的告警值

[root@prometheus-server ~]# vim /etc/prometheus/rules/node_alerts.yml 

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job='node'} == 0
    for: 2m
    labels:
      severity: "critical"
      env: dev
    annotations:
      summary: Host {{ $labels.instance }} of {{ $labels.job }} is Down!
  - alert: OSLoad
    expr: node_load1 > 1
    for: 2m
    labels:
      severity: "warning"
      env: dev
    annotations:
      summary: "主機 {{ $labels.instance }} 負載大於 1"
      description: "當前值: {{ $value }}"
  - alert: HightCPU
    expr: 100-avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)*100 > 10
    for: 2m
    labels:
      severity: "warning"
    annotations:
      summary: "主機 {{ $labels.instance }} of CPU 使用率大於10%!"
      description: "當前值: {{ $value }}%"

以上3個報警規則，node_alerts是監控node_exporter服務狀態，OSLoad是監控系統負載，HightCPU是監控系統cpu使用率，前兩個有標簽env: dev,后面2個有標簽 severity: "warning",重啟Prometheus服務，可以看到監控規則已經加載

 

 1.2 定義alertmanager報警組：

[root@prometheus-server ~]# vim /etc/alertmanager/alertmanager.yml
global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '****@163.com'
  smtp_auth_username: '****@163.com'
  smtp_auth_password: '****'   ## 授權碼
  smtp_require_tls: false

route:
  group_by: ['env']    ### 以標簽env分組，擁有labels為env的規則，如果在指定時間同時報警，報警信息會合並為一條進行發送
  group_wait: 10s　　   ### 組報警等待，等待該組中有沒有其它報警
  group_interval: 30s  ### 組報警時間間隔
  repeat_interval: 2m  ### 重復報警時間，這個生產中跟據服務選擇合適的時間
  receiver: dev-mail ## 接收者

receivers:
- name: 'dev-mail'   ## 對應上面的接收者
  email_configs:
  - to: '****@vanje.com.cn'

 1.3 驗證

　　我們停掉一台主機node_exporter(10.10.0.12)服務，用壓測工具使某一台機器(10.10.0.11)負載大於1，cpu使用率(10.10.0.11)大於10，看下報警郵件是否會按我們定義組進行報警：

　　雖然我們同時觸發了三個報警，但是跟據我們的定義，應該只會發兩條報警信息，因為擁有env標簽的報警規則，同時報警，會被合並為一條發送。

　　觸發報警查看Prometheus ui界面上的alerts：

　　

    等2分鍾后，如果檢測到機器還是處於觸發告警狀態，Prometheus把會告警信息發送至alertmanager，然后跟據報警定義進行郵件報警：

   

 

 上圖從alertmanager報警界面可以看到，報警信息已經按照分組合並，接下來我們看下郵箱中報警信息：

分組總結：

　　1、alertmanager跟據標簽進行分組時，應該選擇合適的標簽，標簽可以自定義，也可以使用默認的標簽。

　　2、alertmanager報警分組，可以有效減少告警郵件數，但是僅是在同一個時間段報警，同一個組的告警信息才會合並發送。

 二、告警抑制(Inhibition)

  2.1 修改Prometheus 報警規則文件，為報警信息添加新標簽area: A

[root@prometheus-server ~]# vim /etc/prometheus/rules/node_alerts.yml 
groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job='node'} == 0
    for: 2m
    labels:
      severity: "critical"
      env: dev
      area: A     annotations:
      summary: Host {{ $labels.instance }} of {{ $labels.job }} is Down!
  - alert: OSLoad
    expr: node_load1 > 0.6
    for: 2m
    labels:
      severity: "warning"
      env: dev
      area: A
    annotations:
      summary: "主機 {{ $labels.instance }} 負載大於 1"
      description: "當前值: {{ $value }}"
  - alert: HightCPU 
    expr: 100-avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)*100 > 10
    for: 2m  
    labels: 
      severity: "warning" area: A
    annotations:
      summary: "主機 {{ $labels.instance }} of CPU 使用率大於10%!"
      description: "當前值: {{ $value }}%"

   2.2 修改alertmanager配置文件

[root@prometheus-server ~]# vim /etc/alertmanager/alertmanager.yml
## 新增以下配置
inhibit_rules:
  - source_match:      ## 源報警規則
      severity: 'critical' 
    target_match:      ## 抑制的報警規則
      severity: 'warning'
    equal: ['area']    ## 需要都有相同的標簽及值，否則抑制不起作用

2.3 驗證

跟上面一樣手動觸發三個規則告警，跟據定義規則，應該只會收到一條報警信息：

查看Prometheus告警都已經觸發，狀態變為PENDING狀態

等待2分鍾后， 三個告警狀態由PENDING 變為 FIRING，同時prometheus會把告警信息發給alertmanager。

Alertmanager中我們只看到一條InstanceDown報警信息。

  查看郵件中，也只收到InstanceDown的報警，另外2條報警已經被配置的抑制規則，把報警信息忽略掉。

 抑制總結：

　　1、抑制是指當警報發出后，停止重復發送由此警報引發其他錯誤的警報的機制。(比如網絡不可達，服務器宕機等災難性事件導致其他服務連接相關警報)；

　　2、配置抑制規則，需要合理源規則及需要抑制的規則；

　　3、源規則與抑制規則需要具有相同的標簽及標簽值；