上一篇（//www.greatytc.com/p/b15217e8f24f
）文章简单介绍了监控神器prometheus的安装、配置、可视化等的使用。这篇我们来讲讲报警。
我们先简单回顾下prometheus的功能和原理。
从上图可以看出通过各种exporter采集数据后，prometheus把各种metrics（指标）统一pull到时间序列数据库中后，我们可以在可视化平台比如grafana显示后，如果有某些指标有异常可以把异常信息push推送给 alertmanager报警平台，报警平台进行处理后notify通知给指定的通道和指定的人。
这时候该Alertmanager报警平台登场了。
一、 Prometheus Alertmanager报警平台简介
报警在Prometheus的架构中被划分成两个独立的部分。如下图，通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager推送报警信息。
Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server，当然也可以是其它的客户端程序的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且分发到通知通道。Alertmanager几个通道：
- 邮件
- HipChat
- OpsGenie
- Slack （国外很火）
- wechat（微信，由于微信的现在仅限微信企业号）
- Webhook
当然Alertmanager不可能集成所有的通道，但是通过Webhook可以二次开发以支持更多定制化的场景。
例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。
已经有好人心实现了钉钉的webhook：https://github.com/timonwong/prometheus-webhook-dingtalk
Alertmanager特性
AlertManager 贴心的提供了报警分组去重、静默和告警抑制机制来对告警通知行为进行优化，比如升级系统需要两个小时，那么这两个小时就不需要对该系统的下线进行烦人的报警了，这个时候在AlertManager的WebUI上可以对该报警进行静默。下面对Alertmanager特性进行更细致的介绍。
1. 分组和去重
在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知。
2. 抑制（Inhibition）
Inhibition字面上翻译是：抑制，但是从意思来讲：收敛这个词会更好（但是收敛其实已经包含了前面讲的分组和去重）。
Inhibition是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。
例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。
3. 静默
静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。例如上面提到的系统升级场景。
4. 告警延时
假设系统发生故障产生告警，每分钟发送一条告警消息，这样的告警信息十分令人崩溃。当然贴心的prometheus也为你想到了。Alertmanager提供第一个参数是repeat_interval，可以将重复的告警以更大频率发送。
不过对于告警延，需要和两个参数配合起来使用
- 解决告警不能及时收到。假设当前发送一条告警，下一次告警在一个小时之后，但在这一个小时之内系统产生了一条告警，这时告警无法被及时发出去。alertmanager提供了第二个参数group_inteval，让报警能够及时的发送出去。
- 另一个问题，当故障发生时，告警条件一个个被满足，到达Alertmanager的顺序也分先后，所以在最开始的时候可能收到多个消息。Alertmanager提供了第三个参数叫做group_wait，在一个分组收到第一条报警消息之后，通过等到group wait，把故障最开始发生时候产生告警收敛掉，最后作为一条消息发送出来。
啰嗦了这么多，相信你已经迫不及待要开始安装试用了。那我们开始吧。
二、AlertManager安装配置
安装
Alertmanager最新版本的下载地址可以从Prometheus官方网站https://prometheus.io/download/获取。
下载完成后，执行tar命令解压即可
tar -xzvf alertmanager-$VERSION.darwin-amd64.tar.gz
Alertmanager解压后会包含一个默认的alertmanager.yml配置文件，修改内容：
global:
resolve_timeout: 5m
smtp_from: 'xxx@xxx.com'
smtp_smarthost: 'smtp.exmail.qq.com:465'
smtp_auth_username: 'xxx@xxx.com'
smtp_auth_password: 'xxx'
smtp_require_tls: false
smtp_hello: 'Alert'
templates:
- 'template/*.tmpl'
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 10m
receiver: 'email.tech'
receivers:
- name: 'email.tech'
webhook_configs:
- url: 'http://127.0.0.1:8060/dingtalk/tech1/send' ## dingding webhook
send_resolved: true
email_configs:
- to: 'userxxx1@xxx.com,user2xxxx@xxx.com' # 多个用户用逗号隔开
headers: {Subject: "异常报警"}
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
简单对上面的配置做下解释
Alertmanager的配置主要包含两个部分：
- 路由(route)
- 接收器(receivers)。
所有的告警信息都会从配置中的顶级路由(route)进入路由树，根据路由规则将告警信息发送给相应的接收器。在配置文件中使用route定义了顶级的路由，路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收器发送告警。
启动
由于golang的特性，启动Alertmanager很简单。进行刚刚解压后的文件夹中，执行
./alertmanager --config.file=alertmanager.yml
关联Prometheus Server与Alertmanager
前面的架构图中已经说明，Alertmanager是独立的组件，告警信息通过Prometheus Server 推送过来。所以需要做Prometheus Server中配置关联以及告警规则。当然也很简单。
编辑Prometheus配置文件prometheus.yml,并添加以下内容：
rule_files:
- /etc/prometheus/rules/*.rules.yml #告警规则文件存放目录
alerting:
alertmanagers:
- static_configs:
targets: ['localhost:9093'] #Alertmanager和Prometheus Server部署在同一台主机
添加告警规则文件
例如，vi /etc/prometheus/rules/load_over1.rules.yml，添加一个load1超过3就告警的规则
groups:
- name: load1
rules:
- alert: Load1Over
expr: (node_load1)> 3
for: 30s
labels:
user: root
annotations:
summary: '【预警】{{$labels.instance}}:load1>3'
description: '{{$labels.instance}}: 【预警】load1 大于3 (current value is:{{$value }})'
接收报警信息
笔者按照上面的配置收到的报警示例如下（钉钉的webhook请查看github安装指引）
1，邮件报警
2，钉钉报警
三、总结
当故障发生时，能够即时获取到异常结果我们要用监控系统的最主要的目的之一。通过Prometheus提供的告警以及告警处理能力，通过内置的告警通知能力，能过帮助用户快速实现告警的通知。同时其还提供了简单有效的扩展方式，让用户可以基于Prometheus的告警处理模式实现更多的定制化需求。
当然笔者这篇文章写的比较简单，还有很多高级特性没有介绍，比如模板等，期待聪明的你自行更深入去理解吧。
