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的配置相对简单,没啥可以说的。提供一个样例配置文件。


- name:   - to:
- name: - name: - service_key: <team-DB-key> - name: 'opt-webhook'


官方提供很多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来进行报警的分组,多条消息一起发送。
  • 抑制: 重要报警抑制低级别报警。
  • 静默: 故障静默,确保在接下来的时间内不会在收到同样报警信息。