一、抑制机制
Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。例如当集群不可用时，用户可能只希望接收到一条告警，告诉他这时候集群出现了问题，而不是大量的如集群中的应用异常、中间件服务异常的告警通知。
在Alertmanager配置文件中，使用inhibit_rules定义一组告警的抑制规则：
inhibit_rules: [ - <inhibit_rule> ... ]
每一条抑制规则的具体配置如下：
target_match: [ <labelname>: <labelvalue>, ... ] target_match_re: [ <labelname>: <regex>, ... ] source_match: [ <labelname>: <labelvalue>, ... ] source_match_re: [ <labelname>: <regex>, ... ] [ equal: '[' <labelname>, ... ']' ]
当已经发送的告警通知匹配到target_match和target_match_re规则，当有新的告警规则如果满足source_match或者定义的匹配规则，并且已发送的告警与新产生的告警中equal定义的标签完全相同，则启动抑制机制，新的告警不会发送。
具体配置
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
二、临时静默
除了基于抑制机制可以控制告警通知的行为以外，用户或者管理员还可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知。
用于停机维护，或者有一个不需要处理的告警信息
http://192.168.10.14:9093/#/alerts
- 创建静默规则
进入Alertmanager UI，点击"Silences"---在点右上角的"New Silence"显示如下内容：
或者
进入Alertmanager UI，点击“点击Alerts”----那个服务多长时间不需要报警
定义静默规则的开始时间以及持续时间和结束时间，通过Matchers部分可以设置多条匹配规则(字符串匹配或者正则匹配)。填写当前静默规则的创建者以及创建原因后，点击"Create"按钮即可。
通过"Preview Alerts"可以查看预览当前匹配规则匹配到的告警信息。静默规则创建成功后，Alertmanager会开始加载该规则并且设置状态为Pending,当规则生效后则进行到Active状态。
- 查看静默规则
点击”silences“在“Active”查看正在运行的静默规则
- 匹配告警信息失效
当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息。
- 取消静默规则
对于已经生效的规则，用户可以通过手动点击”Expire“按钮使当前规则过期。
三、路由匹配
每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re)，每一个路由都可以定义自己的接受人以及匹配规则。默认情况下，告警进入到顶级route后会遍历所有的子节点，直到找到最深的匹配route，并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。
其中告警的匹配有两种方式可以选择。一种方式基于字符串验证，通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。
如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。
案例1：根据服务名称匹配
route:
group_by: ['alertname'] //定义分组,根据label标签进行分组
group_wait: 10s //分组等待时间，也就是说在10秒内同一个组中有没有一起报警的，如果有则同时发出报警邮件，也就是有2个报警同时发在一个邮件
group_interval: 10s //告警时间间隔
repeat_interval: 10m //重复告警间隔，也就是触发的一个告警在10分钟内没有处理则再次发一封邮件。
continue: false //若路由上的continue字段的值为false，则遇到第一个匹配的路由分支后即终止。否则，将继续匹配后续的子节点;
receiver: 'receiver-01' //默认邮箱
routes: //启用一个子路由
- receiver: 'receiver-dba' //接收者为receiver-dba
group_wait: 10s //分组等待时间
match_re: //匹配一个正则
service: mysql|db //service标签包含mysql和db的统一发送给dba的邮箱
continue: false //若路由上的continue字段的值为false，则遇到第一个匹配的路由分支后即终止。否则，将继续匹配后续的子节点;
- receiver: 'receiver-01' //接收者为receiver-01
group_wait: 10s //分组时间
match:
serverity: error //将serverity标签值包含error的发送给yunwei的邮箱
continue: false //若路由上的continue字段的值为false，则遇到第一个匹配的路由分支后即终止。否则，将继续匹配后续的子节点;
receivers: //定义接收者的邮箱
- name: 'receiver-01' //接收者名字，要和routes中的receiver对应
email_configs:
- to: '11111@qq.com' //receiver-01的邮箱地址
- name: 'receiver-dba' //接收者名字，要和routes中的receiver对应
email_configs:
- to: '2222@qq.com' //receiver-dba的邮箱地址
案例2：根据告警规则名称匹配
route:
group_by: ['instance'] # 根据 instance 标签分组
continue: true # 为true则还需要去匹配子路由。
receiver: receiver-01
routes:
- receiver: 'receiver-01'
match:
alertname: 'InstanceDown' # 告警的名字是 InstanceDown 则发送给 receiver-03
- receiver: 'webchat'
match_re:
alertname: 'Cpu.*' # 告警的名字以 Cpu开头的 则发送给 webchat
- receiver: 'dingtalk'
match:
alertname: 'InstanceDown' # 告警的名字是 InstanceDown 则发送给 dingtalk
receivers:
- name: 'receiver-01'
email_configs:
- to: '1111@qq.com'
- name: 'webchat'
webhook_configs:
- url: 'http://192.168.11.61:5000'
send_resolved: true
- name: 'dingtalk'
webhook_configs:
- url: 'http://192.168.11.61:8060/dingtalk/webhook1/send'
send_resolved: true
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 60s
repeat_interval: 24h
receiver: webchat
routes:
- receiver: wechat
group_wait: 10s
continue: true #当消息发送给微信后，继续匹配，就能把消息在发送到钉钉
- receiver: dingtalk
group_wait: 10s
receivers:
- name: 'wechat'
webhook_configs:
- url: 'http://192.168.11.60:8999/webhook?key=自己的key'
- name: 'dingtalk'
webhook_configs:
- url: 'http://192.168.11.60:8060/dingtalk/webhook1/send'
四、告警分组
有的时候为了能够一次性收集和发送更多的相关信息时，可以通过group_wait参数设置等待时间，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送。
而group_interval配置，则用于定义相同的Group之间发送告警通知的时间间隔。
例如，当使用Prometheus监控多个集群以及部署在集群中的应用和数据库服务，并且定义以下的告警处理路由规则来对集群中的异常进行通知。
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
默认情况下所有的告警都会发送给集群管理员default-receiver，因此在Alertmanager的配置文件的根路由中，对告警信息按照集群以及告警的名称对告警进行分组。
如果告警时来源于数据库服务如MySQL或者Cassandra，此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由，如果告警中包含service标签，并且service为MySQL或者Cassandra,则向database-pager发送告警通知，由于这里没有定义group_by等属性，这些属性的配置信息将从上级路由继承，database-pager将会接收到按cluster和alertname进行分组的告警通知。
而某些告警规则来源可能来源于开发团队的定义，这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下，定义单独子路由用于处理这一类的告警通知，如果匹配到告警中包含标签team，并且team的值为frontend，Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常，开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。
告警规则：https://samber.github.io/awesome-prometheus-alerts/rules.html#host-and-hardware
