我们之前讲过，一个完整的监控流程应该是：数据采集(exporter)、采集到数据之后，做数据的可视化(grafana)、然后是监控告警部分，基本上是一个完整的流程。
Prometheus 扮演的角色是，数据的采集，存储、定制告警规则；数据展示则是基于grafana、告警则是借助Alertmanager来实现。

告警工作过程

在Prometheus Server中定义告警规则以及产生告警，Alertmanager组件则用于处理这些由Prometheus产生的告警。Alertmanager即Prometheus体系中告警的统一处理中心。

Alertmanager提供了多种内置第三方告警通知方式，同时还提供了对Webhook通知的支持，通过Webhook用户可以完成对告警更多个性化的扩展。

prometheus触发一条告警的过程：
prometheus—->触发阈值—->超出持续时间—->alertmanager—->分组|抑制|静默—->媒体类型—->邮件|钉钉|微信等。

AlertManager特性

Alertmanager除了提供基本的告警通知能力以外，还主要提供了如：分组、抑制以及静默等告警特性：

分组：

分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。

抑制：

当警报发出后，停止重复发送由此警报引发的其他警报。可以消除冗余告警。

静默：

是一种简单的特定时间静音的机制。例如：服务器要升级维护可以先设置这个时间段告警静默。类似zabbix的维护功能。

Alertmanager部署

1 下载安装

[admin@localhost prometheus-download]$ wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
[admin@localhost prometheus-download]$ tar -xf alertmanager-0.21.0.linux-amd64.tar.gz
[admin@localhost prometheus-download]$ cd alertmanager-0.20.0.linux-amd64
[admin@localhost alertmanager-0.21.0.linux-amd64]$ ll
total 51652
-rwxr-xr-x. 1 admin admin 28871879 Jun 17 16:54 alertmanager
-rw-r--r--. 1 admin admin      842 Nov 26 23:01 alertmanager.yml
-rwxr-xr-x. 1 admin admin 23987848 Jun 17 16:55 amtool
drwxrwxr-x. 2 admin admin     4096 Nov 25 17:19 data
-rw-r--r--. 1 admin admin    11357 Jun 17 17:34 LICENSE
-rw-r--r--. 1 admin admin      457 Jun 17 17:34 NOTICE
drwxrwxr-x. 2 admin admin     4096 Nov 25 23:08 template

2 定义一下分组和路由

cat alertmanager.yml 
# 全局配置项
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.163.com:25'             #使用163邮箱
  smtp_from: 'monitoring2020@163.com'           #邮箱名称
  smtp_auth_username: 'monitoring2020@163.com'  #登录邮箱名称
  smtp_auth_password: 'NHGJPAVAGO00000000'      #授权码,不是登陆密码
  smtp_require_tls: false
  #wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/' # 企业微信地址
# 定义模板信心
templates:
   - 'template/*.tmpl'          #模板路径
route:                          #默认路由
  group_by: ['instance','job']  #根据instance和job标签分组，同标签下的告警会在一个邮件中展现
  group_wait: 30s               # 最初即第一次等待多久时间发送一组警报的通知
  group_interval: 5m            # 在发送新警报前的等待时间
  repeat_interval: 10h          #重复告警间隔
  receiver: email               #默认接收者的名称，以下receivers name的名称
  routes:                       #子路由，不满足子路由的都走默认路由
  - receiver: leader
    match:                      #普通匹配
      severity: critical        #报警规则中定义的报警级别
  - receiver: support_team
    match_re:                   #正则匹配
      severity: ^(warn|critical)$
receivers:                      #定义三个接受者，和上面三个路由对应
- name: 'email'
    email_configs:
  - to: 'jordan@163.com'
- name: 'leader'
  email_configs:
  - to: 'jordan@wicre.com'
- name: 'support_team'
  email_configs:
  - to: 'mlkdesti@163.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
    headers: { Subject: "[WARN] 报警邮件"}  # 接收邮件的标题
    send_resolved: true    #恢复的时候发送告警消息
    webhook_configs: # webhook配置
    - url: 'http://127.0.0.1:5001'
    send_resolved: true
    wechat_configs: # 企业微信报警配置
    - send_resolved: true
      to_party: '1' # 接收组的id
      agent_id: '1000002' # (企业微信-->自定应用-->AgentId)
      corp_id: '******' # 企业信息(我的企业-->CorpId[在底部])
      api_secret: '******' # 企业微信(企业微信-->自定应用-->Secret)
      message: '{{ template "test_wechat.html" . }}' # 发送消息模板的设定  
# 一个inhibition规则是在与另一组匹配器匹配的警报存在的条件下，使匹配一组匹配器的警报失效的规则。两个警报必须具有一组相同的标签。 
inhibit_rules: 
  - source_match: 
     severity: 'critical' 
    target_match: 
     severity: 'warning' 
    equal: ['alertname', 'dev', 'instance']

注：
1）repeat_interval配置项，对于email来说，此项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝
2）企业微信注册地址：https://work.weixin.qq.com

3 检查一下配置文件相关语法信息

[admin@localhost alertmanager-0.21.0.linux-amd64]$ ./amtool check-config alertmanager.yml
Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 0 inhibit rules
 - 3 receivers
 - 0 templates

4 添加到启动项，并且启动、默认监听9093端口

# cat alertmanager.service 
[Unit]
Description=alertmanager
After=network.target
[Service]
Type=simple
ExecStart=/data01/prometheus-download/alertmanager-0.21.0.linux-amd64/alertmanager --config.file=/data01/prometheus-download/alertmanager-0.21.0.linux-amd64/alertmanager.yml
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -KILL $MAINPID
KillMode=control-group
Restart=on-failure
RestartSec=3s
[Install]
WantedBy=multi-user.target

5 启动

systemctl enable alertmanager
systemctl start alertmanager
systemctl stop alertmanager
systemctl reload alertmanager

6 端口9093

配置 prometheus 规则与alert

1 配置prometheus.yml文件中的alerting部分

修改prometheus.yml文件中的alerting部分，让alertmanger能与Prometheus通信

#Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - 127.0.0.1:9093

2 定义告警文件

#Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
   - "rules/*.yml"

3 告警规则定义

这里简单的从主机down机简单写起：

 # cat node_monitor.yml 
 - name: 主机状态-监控告警  #告警分组，一个组下的告警会整合在一个邮件中
    rules:
    - alert: 主机状态     #监控项名称
      expr: up == 0     #正则表达式,up{job:"linux"} 可以在prometheus查询，自己定义监控状态
      for: 1m           #for选项定义表达式持续时长，0的话代表一满足就触发
      labels:
        severity: critical #定义了一个报警级别的标签，告警发送给不同组的，是基于这个标签进行路由
      annotations:         #邮件中告警内容，可引用变量
        summary: "{{$labels.instance}}:服务器宕机"
        description: "{{$labels.instance}}:服务器延时超过5分钟,请及时查看"

说明：

Prometheus支持使用变量来获取指定标签中的值。比如$labels.<labelname>变量可以访问当前告警实例中指定标签的值。$value可以获取当前PromQL表达式计算的样本值。
在创建规则文件时，建议为不同的监控对象建立不同的告警文件，比如monitoring_redis.yml、monitoring_mysql.yml，这里我们监控主机状态，我们使用monitoring_node.yml
expr是我们比较关注的内容，可以根据promql来写查询表达式：

4 保存退出。重启一下prometheus

我们重启一下prometheus server的配置，然后测试一下关闭某台主机的监控：

[root@host-10-10-2-62 ~]# systemctl stop node_exporter

5 查看alstermanager的状态

6 查看prometheus状态

状态说明 Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。 Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。 Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

7 收到告警信息

定义告警模板

然所有核心的信息已经包含了，但是邮件格式内容可以更优雅直观一些，那么，AlertManager 也是支持自定义邮件模板配置，

1 首先新建一个模板文件

[admin@localhost alertmanager-0.21.0.linux-amd64]$ cat test.tmpl 
{{ define "email.to.html" }}
{{ range .Alerts }}
=========start==========<br>
告警程序: prometheus_alert <br>
告警级别: {{ .Labels.severity }} 级 <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary }} <br>
告警详情: {{ .Annotations.description }} <br>
触发时间: {{ .StartsAt }} <br>
=========end==========<br>
{{ end }}
{{ end }}

文中定义了一个变量，test.html这个变量，可以在配置中引用：

2 修改配置文件，使用模板

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: 'monitoring2020@163.com'
  smtp_auth_username: 'monitoring2020@163.com'
  smtp_auth_password: 'NHGJPAVAGOAZSJZD'
  smtp_require_tls: false
# 定义模板信心
templates:
   - 'template/*.tmpl'   #引用模板
route:
  group_by: ['instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 10h
  receiver: email
  routes:
  - receiver: leader
    match:
      severity: critical
  - receiver: support_team
    match_re:
      severity: ^(warn|critical)$
receivers:                      #定义三个接受者，和上面三个路由对应
- name: 'email'
    email_configs:
  - to: 'jordan@163.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
- name: 'leader'
  email_configs:
  - to: 'jordan@wicre.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
- name: 'support_team'
  email_configs:
  - to: 'mlkdesti@163.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
    headers: { Subject: "[WARN] 报警邮件"}  # 接收邮件的标题

3 测试发送效果

4 恢复告警通知

在上面的时候，发生告警的时候，会送邮件，那么当恢复的时候，我们需要发送邮件恢复正常邮件，只要在配置的时候，加上：send_resolved: true

5、添加恢复消息：
receivers:                      #定义三个接受者，和上面三个路由对应
- name: 'email'
    email_configs:
  - to: 'jordan@163.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
    send_resolved: true    #恢复的时候发送告警消息
- name: 'leader'
  email_configs:
  - to: 'jordan@wicre.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
    send_resolved: true    #恢复的时候发送告警消息
- name: 'support_team'
  email_configs:
  - to: 'mlkdesti@163.com'
    html: '{{ template "test.html" . }}'  # 设定邮箱的内容模板
    headers: { Subject: "[WARN] 报警邮件"}  # 接收邮件的标题
    send_resolved: true    #恢复的时候发送告警消息

5 修改模板，添加恢复消息

#####cat test.tmpl 
{{ define "test.html" }}
{{ if gt (len .Alerts.Firing) 0 }}{{ range .Alerts }}
@故障告警：<br>
告警程序: prometheus_alert <br>
告警级别: {{ .Labels.severity }} 级 <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary }} <br>
告警详情: {{ .Annotations.description }} <br>
触发时间: {{ .StartsAt  }} <br>
{{ end }}
{{ end }}
{{ if gt (len .Alerts.Resolved) 0 }}{{ range .Alerts }}
@故障恢复：<br>
告警主机：{{ .Labels.instance }} <br>
告警主题：{{ .Annotations.summary }} <br>
恢复时间: {{ .EndsAt  }} <br>
{{ end }}
{{ end }}
{{ end }}

6 邮件详情

告警收敛（分组，抑制，静默）

1 分组(group)

将类似性质的警报合并为单个通知。

group_by: ['alertname']  # 以标签作为分组依据
  group_wait: 10s        # 分组报警等待时间
  group_interval: 10s    # 发送组告警间隔时间
  repeat_interval: 1h    # 重复告警发送间隔时间

2 抑制(inhibition)

当警报发出后，停止重复发送由此警报引发的其他警报。可以消除冗余告警

inhibit_rules:
  - source_match:  # 当此告警发生，其他的告警被抑制
      severity: 'critical'   
    target_match:   # 被抑制的对象
      severity: 'warning'  
    equal: ['id', 'instance']

当同时发生warning和critical告警时候，会抑制掉warning的告警，只发送critical的信息。

3 静默(silences)

是一种简单的特定时间静音的机制。例如：服务器要升级维护可以先设置这个时间段告警静默。（类似zabbix 的维护周期）：

可以看到我们没有添加告警静默的时候，这个时候是会收到多个消息。

在alertmanager添加静默：

创建：

当然你也可以用new silence来进行添加，不过这个需要自己手动去匹配，用上面的方式是最方便的。维护结束后，直接删除即可。

5.部署altermanager