一、概述

Prometheus 包含一個報警模塊，就是我們的 AlertManager，Alertmanager 主要用于接收 Prometheus 發(fā)送的告警信息，它支持豐富的告警通知渠道，而且很容易做到告警信息進行去重，降噪，分組等，是一款前衛(wèi)的告警通知系統(tǒng)。

• GitHub地址：https://github.com/prometheus/alertmanager/
• 官方文檔：https://prometheus.io/docs/alerting/latest/alertmanager/

二、AlertManager 架構(gòu)

Alertmanager由以下6部分組成：

• API組件——用于接收Prometheus Server的http請求，主要是告警相關(guān)的內(nèi)容。
• Alert Provider組件——API層將來自Prometheus Server的告警信息存儲到Alert Provider上。
• Dispatcher組件——不斷的通過訂閱的方式從Alert Provider獲取新的告警，并根據(jù)yaml配置的routing tree將告警通過label路由到不同的分組中，以實現(xiàn)告警信息的分組處理。
• Notification Pipeline組件——這是一個責任鏈模式的組件，它通過一系列的邏輯（抑制、靜默、去重）來優(yōu)化告警質(zhì)量。
• Silence Provider組件——API層將來自prometheus server的告警信息存儲到silence provider上，然后由這個組件實現(xiàn)去重邏輯處理。
• Notify Provider組件——是Silence Provider組件的下游，會在本地記錄日志，并通過peers的方式將日志廣播給集群中的其他節(jié)點，判斷當前節(jié)點自身或者集群中其他節(jié)點是否已經(jīng)發(fā)送過了，避免告警信息在集群中重復(fù)出現(xiàn)。

三、AlertManager 部署

下載地址：https://prometheus.io/download/

1）下載

wget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gz
tar -xf alertmanager-0.24.0.linux-amd64.tar.gz

2）配置

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
  - name: 'web.hook'
    webhook_configs:
      - url: 'http://127.0.0.1:5001/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

Alertmanager配置中一般會包含以下幾個主要部分：

• 全局配置（global）：用于定義一些全局的公共參數(shù)，如全局的SMTP配置，Slack配置等內(nèi)容。
• 模板（templates）：用于定義告警通知時的模板，如HTML模板，郵件模板等。
• 告警路由（route）：根據(jù)標簽匹配，確定當前告警應(yīng)該如何處理。
• 接收人（receivers）：接收人是一個抽象的概念，它可以是一個郵箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用。
• 抑制規(guī)則（inhibit_rules）：合理設(shè)置抑制規(guī)則可以減少垃圾告警的產(chǎn)生。

具體字段解釋：

• global 這個是全局設(shè)置
• resolve_timeout 當告警的狀態(tài)有firing變?yōu)閞esolve的以后還要呆多長時間，才宣布告警解除。這個主要是解決某些監(jiān)控指標在閥值邊緣上波動，一會兒好一會兒不好。
• route 是個重點，告警內(nèi)容從這里進入，尋找自己應(yīng)該用那種策略發(fā)送出去。
• receiver 一級的receiver，也就是默認的receiver，當告警進來后沒有找到任何子節(jié)點和自己匹配，就用這個receiver。
• group_by 告警應(yīng)該根據(jù)那些標簽進行分組。
• group_wait 同一組的告警發(fā)出前要等待多少秒，這個是為了把更多的告警一個批次發(fā)出去。
• group_interval 同一組的多批次告警間隔多少秒后，才能發(fā)出。
• repeat_interval 重復(fù)的告警要等待多久后才能再次發(fā)出去。
• routes 也就是子節(jié)點了，配置項和上面一樣。告警會一層層的找，如果匹配到一層，并且這層的continue選項為true，那么他會再往下找，如果下層節(jié)點不能匹配那么他就用區(qū)配的這一層的配置發(fā)送告警。如果匹配到一層，并且這層的continue選項為false，那么他會直接用這一層的配置發(fā)送告警，就不往下找了。
• match_re 用于匹配label。此處列出的所有l(wèi)abel都匹配到才算匹配。
• inhibit_rules這個叫做抑制項，通過匹配源告警來抑制目的告警。比如說當我們的主機掛了，可能引起主機上的服務(wù)，數(shù)據(jù)庫，中間件等一些告警，假如說后續(xù)的這些告警相對來說沒有意義，我們可以用抑制項這個功能，讓Prometheus只發(fā)出主機掛了的告警。
• source_match 根據(jù)label匹配源告警。
• target_match 根據(jù)label匹配目的告警。
• equal 此處的集合的label，在源和目的里的值必須相等。如果該集合的內(nèi)的值再源和目的里都沒有，那么目的告警也會被抑制。

3）啟動服務(wù)

# 查看幫助
./alertmanager -h
# 可以直接啟動，但是不提倡，最好配置alertmanager.service
./alertmanager

配置alertmanager.service啟動腳本

# 默認端口9093
cat >/usr/lib/systemd/system/alertmanager.service<<EOF
[Unit]
Description=alertmanager

[Service]
WorkingDirectory=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64
ExecStart=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/alertmanager --config.file=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/alertmanager.yml --storage.path=/opt/prometheus/alertmanager/alertmanager-0.24.0.linux-amd64/data --web.listen-address=:9093 --data.retention=120h
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

啟動服務(wù)

# 執(zhí)行 systemctl daemon-reload 命令重新加載systemd
systemctl daemon-reload
# 啟動
systemctl start alertmanager
# 檢查
systemctl status alertmanager
netstat -tnlp|grep :9093

web訪問：http://ip:9093

4）與Prometheus集成

修改Prometheus的配置文件，修改配置如下：

重啟Prometheus

systemctl restart prometheus

四、在Prometheus中設(shè)置告警規(guī)則

在Prometheus 配置中添加報警規(guī)則配置，配置文件中 rule_files 就是用來指定報警規(guī)則文件的，如下配置即指定存放報警規(guī)則的目錄為/etc/prometheus，規(guī)則文件為rules.yml：

rule_files:
- /etc/prometheus/rules.yml

設(shè)置報警規(guī)則：

警報規(guī)則允許基于 Prometheus 表達式語言的表達式來定義報警報條件的，并在觸發(fā)警報時發(fā)送通知給外部的接收者（Alertmanager），一條警報規(guī)則主要由以下幾部分組成：

• alert——告警規(guī)則的名稱。
• expr——是用于進行報警規(guī)則 PromQL 查詢語句。
• for——評估告警的等待時間（Pending Duration）。
• labels——自定義標簽，允許用戶指定額外的標簽列表，把它們附加在告警上。
• annotations——用于存儲一些額外的信息，用于報警信息的展示之類的。

rules.yml如下所示：

groups:
- name: example
  rules:
  - alert: high_memory
    # 當內(nèi)存占有率超過10%，持續(xù)1min,則觸發(fā)告警
    expr: 100 - ((node_memory_MemAvailable_bytes{instance="192.168.182.110:9100",job="node_exporter"} * 100) / node_memory_MemTotal_bytes{instance="192.168.182.110:9100",job="node_exporter"}) > 90
    for: 1m
    labels:
      severity: page
    annotations:
      summary: spike memeory 

五、AlertManager 告警通道配置

## Alertmanager 配置文件
global:
  resolve_timeout: 5m
  # smtp配置
  smtp_from: "xxx@qq.com"
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: "xxx@qq.com"
  smtp_auth_password: "auth_pass"
  smtp_require_tls: true

# email、企業(yè)微信的模板配置存放位置，釘釘?shù)哪０鍟为氈v如果配置。
templates:
  - '/data/alertmanager/templates/*.tmpl'
# 路由分組
route:
  receiver: ops
  group_wait: 30s # 在組內(nèi)等待所配置的時間，如果同組內(nèi)，30秒內(nèi)出現(xiàn)相同報警，在一個組內(nèi)出現(xiàn)。
  group_interval: 5m # 如果組內(nèi)內(nèi)容不變化，合并為一條警報信息，5m后發(fā)送。
  repeat_interval: 24h # 發(fā)送報警間隔，如果指定時間內(nèi)沒有修復(fù)，則重新發(fā)送報警。
  group_by: [alertname]  # 報警分組
  routes:
      - match:
          team: operations
        group_by: [env,dc]
        receiver: 'ops'
      - match_re:
          service: nginx|apache
        receiver: 'web'
      - match_re:
          service: hbase|spark
        receiver: 'hadoop'
      - match_re:
          service: mysql|mongodb
        receiver: 'db'
# 接收器
# 抑制測試配置
      - receiver: ops
        group_wait: 10s
        match:
          status: 'High'
# ops
      - receiver: ops # 路由和標簽，根據(jù)match來指定發(fā)送目標，如果 rule的lable 包含 alertname， 使用 ops 來發(fā)送
        group_wait: 10s
        match:
          team: operations
# web
      - receiver: db # 路由和標簽，根據(jù)match來指定發(fā)送目標，如果 rule的lable 包含 alertname， 使用 db 來發(fā)送
        group_wait: 10s
        match:
          team: db
# 接收器指定發(fā)送人以及發(fā)送渠道
receivers:
# ops分組的定義
- name: ops
  email_configs:
  - to: '9935226@qq.com,10000@qq.com'
    send_resolved: true
    headers:
      subject: "[operations] 報警郵件"
      from: "警報中心"
      to: "小煜狼皇"
  # 釘釘配置
  webhook_configs:
  - url: http://localhost:8070/dingtalk/ops/send
    # 企業(yè)微信配置
  wechat_configs:
  - corp_id: 'ww5421dksajhdasjkhj'
    api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
    send_resolved: true
    to_party: '2'
    agent_id: '1000002'
    api_secret: 'Tm1kkEE3RGqVhv5hO-khdakjsdkjsahjkdksahjkdsahkj'

# web
- name: web
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[web] 報警郵件"} # 接收郵件的標題
  webhook_configs:
  - url: http://localhost:8070/dingtalk/web/send
  - url: http://localhost:8070/dingtalk/ops/send
# db
- name: db
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[db] 報警郵件"} # 接收郵件的標題
  webhook_configs:
  - url: http://localhost:8070/dingtalk/db/send
  - url: http://localhost:8070/dingtalk/ops/send
# hadoop
- name: hadoop
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: { Subject: "[hadoop] 報警郵件"} # 接收郵件的標題
  webhook_configs:
  - url: http://localhost:8070/dingtalk/hadoop/send
  - url: http://localhost:8070/dingtalk/ops/send

# 抑制器配置
inhibit_rules: # 抑制規(guī)則
  - source_match: # 源標簽警報觸發(fā)時抑制含有目標標簽的警報，在當前警報匹配 status: 'High'
      status: 'High'  # 此處的抑制匹配一定在最上面的route中配置不然，會提示找不key。
    target_match:
      status: 'Warning' # 目標標簽值正則匹配，可以是正則表達式如: ".*MySQL.*"
    equal: ['alertname','operations', 'instance'] # 確保這個配置下的標簽內(nèi)容相同才會抑制，也就是說警報中必須有這三個標簽值才會被抑制。

一般企業(yè)釘釘、郵件、webhook告警通道比較常用，尤其是webhook，一般都會通過webhook對接公司內(nèi)部的統(tǒng)一告警平臺。