一、 配置概述
Alertmanager主要负责对Prometheus产生的告警进行统一处理，在Alertmanager配置中一般会包含以下几个主要部分：
- 全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
- 模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
- 告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
- 接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
- 抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生
二、 告警路由
1. 配置详解
告警路由可以使我们的告警根据不同的标签告警匹配到不同的渠道发送处理。配置文件解析如下：
route: #配置路由树
receiver: # 接收组名，对于不同级别的告警，我们可能多个完全不同的接收组进行处理。
group_by: []# 根据label标签的key进行匹配，如果是多个，就要多个都匹配
continue: false # 告警是否去继续路由子节点
match: [labelname:labelvalue,labelname1,labelvalue1] # 通过标签去匹配这次告警是否符合这个路由节点。
match_re: [labelname:regex] # 通过正则表达是匹配标签，意义同上
group_wait: 30s # 组内等待时间，同一分组内收到第一个告警等待多久开始发送，目标是为了同组消息同时发送，不占用告警信息，默认30s
group_interval: 5m # 当组内已经发送过一个告警，组内若有新增告警需要等待的时间，默认为5m,这条要确定组内信息是影响同一业务才能设置，若分组不合理，可能导致告警延迟，造成影响
repeat_inteval: 4h # 告警已经发送，且无新增告警，若重复告警需要间隔多久 默认4h 属于重复告警，时间间隔应根据告警的严重程度来设置
routes:
- route: #路由子节点 配置信息跟主节点的路由信息一致2. 路由匹配
每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re)，每一个路由都可以定义自己的接受人以及匹配规则。默认情况下，告警进入到顶级route后会遍历所有的子节点，直到找到最深的匹配route，并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。
其中告警的匹配有两种方式可以选择。一种方式基于字符串验证，通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。
如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。
3. 告警分组
Alertmanager可以对告警通知进行分组，将多条告警合合并为一个通知，避免短期内频繁收到多条相关告警。这里我们可以使用group_by来定义分组规则。基于告警中包含的标签，如果满足group_by中定义标签名称，那么这些告警将会合并为一个通知发送给接收器。
有的时候为了能够一次性收集和发送更多的相关信息时，可以通过group_wait参数设置等待时间，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送。
而group_interval配置，则用于定义相同的Group之间发送告警通知的时间间隔。
4. 示例：告警分组功能的实现
- 默认情况下所有的告警都会发送给管理员default-receiver，因此在Alertmanager的配置文件的根路由中，对告警信息按照集群以及告警的名称对告警进行分组。
- 如果告警是来源于数据库服务如MySQL或者pgsql，此时则需要将告警发送给相应的数据库管理员(dba)。这里定义了一个单独子路由，如果告警中包含service标签，并且service为mysql或者pgsql,则向dba-pager发送告警通知，由于这里没有定义group_by等属性，这些属性的配置信息将从上级路由继承，dba-pager将会接收到按cluser和alertname进行分组的告警通知。
- 而某些告警规则来源可能来源于开发团队，这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下，定义单独子路由用于处理这一类的告警通知，如果匹配到告警中包含标签team，并且team的值为dev，Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常，开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'dba-pager'
group_wait: 10s
match_re:
service: mysql|pgsql
- receiver: 'dev-pager'
group_by: [product, environment]
match:
team: dev
receivers:
- name: 'default-receiver'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
- name: 'dba-pager'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
- name: 'dev-pager'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
5. 示例：告警分级功能的实现
- 在每条告警配置的标签中添加severity配置，有三种等级，分别为warning、critical和emergency。严重等级依次递增。
- 不论收到那种等级的告警，都会邮件通知给默认的管理员default-receiver
- 当告警等级为critical时，比较严重的告警，发送短信通知，每2h重复发送一次，直到问题解决
- 当告警等级为emergency时，特别严重的告警，打电话通知，每1h重复发送一次，直到问题解决
三、 告警接收
1. receiver配置介绍
在Alertmanager中路由负责对告警信息进行分组匹配，并向告警接收器发送通知。每一个receiver具有一个全局唯一的名称，并且对应一个或者多个通知方式，告警接收配置如下：
receivers:
- name: # 接收器名称，全局唯一
# Configurations for several notification integrations.
email_configs:
[ - <email_config>, ... ]
pagerduty_configs:
[ - <pagerduty_config>, ... ]
pushover_configs:
[ - <pushover_config>, ... ]
slack_configs:
[ - <slack_config>, ... ]
opsgenie_configs:
[ - <opsgenie_config>, ... ]
webhook_configs:
[ - <webhook_config>, ... ]
victorops_configs:
[ - <victorops_config>, ... ]
wechat_configs:
[ - <wechat_config>, ... ]
- name: # 另一个接收器名称，全局唯一
………………四、 告警静默
假设节点1持续处于宕机状态，并配置了repeat_interval: 1h，也就是如果故障没有解决，每1h会通知一次，直到故障恢复。但有可能这台服务器硬件损坏，短期内无法恢复，为了避免告警打扰，可以设置临时静默。
五、 告警抑制
Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。例如当集群不可用时，用户可能只希望接收到一条告警，告诉他这时候集群出现了问题，而不是大量的如集群中的应用异常、中间件服务异常的告警通知。
1. 模拟3条告警
服务器宕机
nginx服务停止
nginx端口不通
由于nginx部署的服务器突然宕机，导致nginx服务停止、端口不存在。同时触发3条告警规则，收到3条告警通知。这种情况一般只需要通知告警优先级较高的告警，受关联告警不进行通知。
2. 模拟抑制
首先对nginx服务异常、网络端口异常告警增加一个标签【project:test-web】,标注这两种告警属同一业务。
页面查看抑制规则是否被读取。
第一条抑制规则为：当收到告警【服务器宕机】并且【host=192.168.3.154】时，触发抑制规则，后续收到的告警带有【project:test-web】标签的告警全部被抑制。（也就是服务器宕机时，nginx服务停止、端口不通的告警不再通知）
第二条抑制规则为：当收到告警标签中带有【severity=critical】标签时，触发抑制规则，后续收到告警带有【severity=warning】标签的告警全部被抑制。需要注意的是，这里还添加了【equal】标签，作用是source和target中都包含project这个标签，且他们的值一致时，才会抑制（也就是抑制nginx网络端口不通的告警）。
3. 测试抑制规则1的告警数据：
服务器宕机，nginx服务停止，网络不通
[{
"labels": {
"team": "dev",
"alertname": "服务器宕机",
"cluster": "127.0.0.1",
"product": "test",
"host": "127.0.0.1",
"severity": "emergency",
"msgtype": "testing"
},
"annotations": {
"info": "服务器宕机",
"locahost": "127.0.0.1",
"summary": "请检查服务器"
}
},
{
"labels": {
"team": "dev",
"alertname": "nginx停止",
"project": "test-web",
"cluster": "127.0.0.1",
"product": "test",
"host": "127.0.0.1",
"severity": "critical",
"msgtype": "testing"
},
"annotations": {
"info": "nginx停止",
"locahost": "127.0.0.1",
"summary": "请检查nginx"
}
},
{
"labels": {
"team": "dev",
"alertname": "nginx网络端口不通",
"project": "test-web",
"cluster": "127.0.0.1",
"product": "test",
"prot": "80",
"severity": "warning",
"msgtype": "testing"
},
"annotations": {
"info": "nginx网络端口不通",
"locahost": "127.0.0.1:80",
"summary": "请检查网络策略"
}
}
]结果：
只存在服务器宕机告警，ngxin服务停止，网络端口不通告警被抑制
4. 测试抑制规则2的告警数据：
nginx服务停止，网络端口不通
[{
"labels": {
"team": "dev",
"alertname": "nginx停止",
"project": "test-web",
"cluster": "127.0.0.1",
"product": "test",
"host": "127.0.0.1",
"severity": "critical",
"msgtype": "testing"
},
"annotations": {
"info": "nginx停止",
"locahost": "127.0.0.1",
"summary": "请检查nginx"
}
},
{
"labels": {
"team": "dev",
"alertname": "nginx网络端口不通",
"project": "test-web",
"cluster": "127.0.0.1",
"product": "test",
"prot": "80",
"severity": "warning",
"msgtype": "testing"
},
"annotations": {
"info": "nginx网络端口不通",
"locahost": "127.0.0.1:80",
"summary": "请检查网络策略"
}
}
]结果：
只存在nginx停止的告警，网络不通告警被抑制
