prometheus學習系列十： Prometheus AlertManager配置文件說明

alertmanager配置文件說明

alertmanager是通過命令行標記和配置文件配置的，命令行標記配置不可變的系統參數，配置文件定義抑制規則、通知路由和通知接收器。可以通過官方提供的routing tree editor 查看配置的路由樹詳細信息。

默認配置文件如下

[root@node00 ~]# cd /usr/local/prometheus/alertmanager/
[root@node00 alertmanager]# cat alertmanager.yml.default 
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  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']

這個默認配置文件時通過一個webhook作為接受者，alertmanager會在報警的時候給這個webhook地址發送一個post請求，提交報警信息， 由webhook內部完成消息發送。 下面的inhibit_rules配置一個抑制規則，就是critical級別的規則抑制warning級別的報警。

 

global配置

• resolve_timeout:  這個解釋有點繞，簡單說就是在報警恢復的時候不是立馬發送的，在接下來的這個時間內，如果沒有此報警信息觸發，才發送報警恢復消息。 默認值為5m。
• smtp_from: 發件人郵箱地址。
• smtp_smarthost: 發件人對應郵件提供商的smtp地址。
• smtp_auth_username: 發件人的登陸用戶名，默認和發件人地址一致。
• smtp_auth_password:  發件人的登陸密碼，有時候是授權碼。
• smtp_require_tls: 是否需要tls協議。默認是true。
• wechart_api_url:  微信api地址。
• wechart_api_secret： 密碼
• wechat_api_corp_id: corp id信息。

 

templates配置

模板用於控制我們發送的消息格式控制和內容組織的，我們可以自定義一個模板， 模板中引用alertmanager提供的一些內置變量，最終完成消息的渲染。

樣例如下：

# alertmanager配置文件
templates:
- '/usr/local/prometheus/alertmanager/templates/myorg.tmpl'

# cat /usr/local/prometheus/alertmanager/templates/myorg.tmpl
{{ define "slack.myorg.text" }}https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}{{ end}}

 

receivers配置

receivers的配置相對簡單，沒啥可以說的。提供一個樣例配置文件。

receivers:
- name: 'email-zhaojiedi'
  email_configs:
  - to: '[e-mail]'

- name: 'hipchat-zhaojiedi' hipchat_configs: - auth_token: <auth_token> room_id: 85 message_format: html notify: true
- name: 'pagerduty-zhaojiedi'
  pagerduty_configs:
  - service_key: <team-DB-key>
- name: 'opt-webhook'
  send_resolved: true 
  url: "http://xxxxx.xxx.com/5002/dingding/xxx/send/

官方提供很多receviers的配置格式， 詳細的參考官方文檔： https://prometheus.io/docs/alerting/configuration/#receiver

route配置

route在這些配置中，相對是比較復雜的，這個配置主要是完成，報警規格會進入路由樹，根據路由規則中的match或者match_re來匹配， 如果匹配中就會選擇一個樹分支來進行，找到此分支對應的receiver來發送對應的消息信息。

如果所有route信息都沒法命中，就采用默認的receiver這個配置來發送消息。

樣例如下：

routes:
  - match_re:
      service: ^(foo1|foo2|baz)$
    receiver: team-X-mails
    routes:
    - match:
        severity: critical
      receiver: team-X-pager
      
  - match:
      service: files
    receiver: team-Y-mails

    routes:
    - match:
        severity: critical
      receiver: team-Y-pager


  - match:
      service: database
    receiver: team-DB-pager
    # Also group alerts by affected database.
    group_by: [alertname, cluster, database]
    routes:
    - match:
        owner: team-X
      receiver: team-X-pager
      continue: true
    - match:
        owner: team-Y
      receiver: team-Y-pager

這個配置文件時從alertmanager官方的github上面找到的。 地址如下：  https://github.com/prometheus/alertmanager/blob/master/doc/examples/simple.yml ， 我們可以通過官方的工具來看下這個路由樹是什么樣的。

 

inhibit_rules配置

我們知道alertmanager對報警有抑制工程， 可以通過一定的規則，抑制一些報警消息，比如如下場景。

場景1 ： 磁盤報警，80%報警設置為info級別，90設置為警告級別， 如果2個消息都發送，那就多余了。 我們需要設置相同報警高級別壓制低級別的報警，只發送高級別的報警信息。

場景2： 節點宕機了， 在這個節點上面的各種服務報警都會觸發的， 如果都發送不太方便定位問題，還容易帶來巨大的壓力。可以配置節點宕機壓制節點層面的其他報警信息。

樣例配置如下：

inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  equal: ['alertname' ]

通過上面的配置，可以在alertname相同的情況下，critaical的報警會抑制warning級別的報警信息。

靜默配置

靜默配置是通過web界面配置的， 如下圖。

 

 進入靜默配置頁面

 

 總結

alertmanager集成報警系統的幾個重要功能。

• 分組：  可以通過route書的group_by來進行報警的分組，多條消息一起發送。
• 抑制： 重要報警抑制低級別報警。
• 靜默： 故障靜默，確保在接下來的時間內不會在收到同樣報警信息。