prometheus学习系列⼗：PrometheusAlertManager配置⽂件说
明
alertmanager配置⽂件说明
alertmanager是通过命令⾏标记和配置⽂件配置的，命令⾏标记配置不可变的系统参数，配置⽂件定义抑制规则、通知路由和通知接收器。可以通过官⽅提供的查看配置的路由树详细信息。
默认配置⽂件如下
[root@node00 ~]# cd /usr/local/prometheus/alertmanager/
[root@node00 alertmanager]# l.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: '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/pl'
# cat /usr/local/prometheus/alertmanager/pl
{{ define "" }}/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}{{ end}}
receivers配置
receivers的配置相对简单，没啥可以说的。提供⼀个样例配置⽂件。
receivers:
- name: 'email-zhaojiedi'
email_configs:
- to: '1072892917@qq'
- 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: "/5002/dingding/xxx/send/
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
inhibit_rules配置
我们知道alertmanager对报警有抑制⼯程，可以通过⼀定的规则，抑制⼀些报警消息，⽐如如下场景。
场景1 ：磁盘报警，80%报警设置为info级别，90设置为警告级别，如果2个消息都发送，那就多余了。我们需要设置相同报警⾼级别压制低级别的报警，只发送⾼级别的报警信息。
场景2：节点宕机了，在这个节点上⾯的各种服务报警都会触发的，如果都发送不太⽅便定位问题，还容易带来巨⼤的压⼒。可以配置节点宕机压制节点层⾯的其他报警信息。resolve a doi name
样例配置如下：
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来进⾏报警的分组，多条消息⼀起发送。
抑制：重要报警抑制低级别报警。
静默：故障静默，确保在接下来的时间内不会在收到同样报警信息。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。