prometheus从入门到实践（2）——prometheus告警处理&部署alertmanager

1、认识prometheus告警

告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示，通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager发送告警信息。

在Prometheus中一条告警规则主要由以下几部分组成：

• 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
• 告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警。

Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

2、alertmanager特性

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

3、自定义告警规则

此时node_exporter要开启。
指定监控文件。在prometheus.yml文件中：

rule_files:
  - '/etc/prometheus/prometheus.rules.yml'

创建规则文件：

[root@prometheus prometheus]# vim /etc/prometheus/prometheus.rules.yml
groups:
- name: hostStatsAlert
  rules:
  - alert: hostCpuUsageAlert
    expr: sum(avg without (cpu)(irate(node_cpu{mode!='idle'}[5m]))) by (instance) > 0.85
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usgae high"
      description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
  - alert: hostMemUsageAlert
    expr: (node_memory_MemTotal - node_memory_MemAvailable)/node_memory_MemTotal > 0.85
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} MEM usgae high"
      description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"

重启Prometheus
注意：要将规则文件映射到docker中

 [root@prometheus prometheus]# docker run -d -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml -v /etc/prometheus/prometheus.rules.yml:/etc/prometheus/prometheus.rules.yml  prom/prometheus

浏览器访问localhost:9090/rules（端口转发，实际在访问虚拟机）

切换到Alerts标签http://localhost:9090/alerts可以查看当前告警的活动状态。

此时，我们可以手动拉高系统的CPU使用率，验证Prometheus的告警流程，在主机上运行以下命令：

cat /dev/zero>/dev/null

运行命令后查看CPU使用率情况，如下图所示：
含义：

avg(irate(node_cpu_seconds_total{mode!="idle"}[5m]))

除cpu的空闲时间之外，所有工作模式下的cpu在5分钟间隔内使用率的平均值。

Prometheus首次检测到满足触发条件后，hostCpuUsageAlert显示由一条告警处于活动状态。由于告警规则中设置了1m的等待时间，当前告警状态为PENDING，如下图所示：

如果1分钟后告警条件持续满足，则会实际触发告警并且告警状态为FIRING，如下图所示：

4、部署alertmanager

（1）取并安装软件包
Alertmanager最新版本的下载地址可以从Prometheus官方网站https://prometheus.io/download/获取。

export VERSION=0.15.2
curl -LO https://github.com/prometheus/alertmanager/releases/download/v$VERSION/alertmanager-$VERSION.darwin-amd64.tar.gz
tar xvf alertmanager-$VERSION.darwin-amd64.tar.gz

（2）创建alertmanager配置文件
Alertmanager解压后会包含一个默认的alertmanager.yml配置文件：

Alertmanager的配置主要包含两个部分：路由(route)以及接收器(receivers)。所有的告警信息都会从配置中的顶级路由(route)进入路由树，根据路由规则将告警信息发送给相应的接收器。

在配置文件中使用route定义了顶级的路由，路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收器发送告警。目前配置文件中只设置了一个顶级路由route并且定义的接收器为default-receiver。因此，所有的告警都会发送给default-receiver。关于路由的详细内容会在后续进行详细介绍。

（3）启动Alertmanager

[root@prometheus ~]# cd alertmanager-0.21.0.linux-amd64
[root@prometheus alertmanager-0.21.0.linux-amd64]# ./alertmanager

用户也在启动Alertmanager时使用参数修改相关配置。–config.file用于指定alertmanager配置文件路径，–storage.path用于指定数据存储路径。

（4）查看运行状态
Alertmanager启动后可以通过9093端口访问，在主机上配置端口转发，然后浏览器访问http://localhost:9093

（5）关联Prometheus与Alertmanager
在Prometheus的架构中被划分成两个独立的部分。Prometheus负责产生告警，而Alertmanager负责告警产生后的后续处理。因此Alertmanager部署完成后，需要在Prometheus中设置Alertmanager相关的信息。
修改prometheus.yml文件：

重启Prometheus服务，成功后，可以从http://localhost:9090/config查看alerting配置是否生效。

此时，再次尝试手动拉高系统CPU使用率：

cat /dev/zero>/dev/null

等待Prometheus告警进行触发状态：

查看Alertmanager UI此时可以看到Alertmanager接收到的告警信息。

5、配置QQ邮箱告警

修改alertmanager.yml文件，5min发送一次告警信息，可以自行配置时间。

[root@prometheus nodegroups]# mkdir /etc/alertmanager
[root@prometheus nodegroups]# cd /etc/alertmanager/
[root@prometheus alertmanager]# vim alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_from: 'xxxxxxxx@qq.com'
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_auth_username: 'xxxxxxxx@qq.com'
  smtp_auth_password: 'xxxxxxxxx'
  smtp_require_tls: false
  smtp_hello: 'qq.com'
route:
  group_by: ['alertname']
  group_wait: 5s
  group_interval: 5s
  repeat_interval: 5m
  receiver: 'email'
receivers:
 - name: 'email'
  email_configs:
 - to: 'xxxxxxxxx@qq.com'
    send_resolved: true
inhibit_rules:
 - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

参数含义：

• global: 全局配置，包括报警解决后的超时时间、SMTP 相关配置、各种渠道通知的 API 地址等等。
• resolve_timeout:
  简单说就是在报警恢复的时候不是立马发送的，在接下来的这个时间内，如果没有此报警信息触发，才发送报警恢复消息。 默认值为5m
• smtp_smarthost: 发件人对应邮件提供商的smtp地址。
• smtp_auth_username:发件人的登陆用户名，默认和发件人地址一致。
• smtp_auth_password: 这里为第三方登录 QQ 邮箱的授权码，非 QQ
  账户登录密码，否则会报错，获取方式在 QQ 邮箱服务端设置开启POP3/SMTP服务时会提示。
• smtp_require_tls:是否需要tls协议。默认是true。 route: 用来设置报警的分发策略，它是一个树状结构，按照深度优先从左向右的顺序进行匹配.
• group_by:分组一起发送，不在组内则单独发送。 group_wait:初次发送告警延时
• group_interval:距离第一次发送告警，等待多长时间再次发送告警
• repeat_interval: 5m告警未解决时，重发告警等待时间5min receivers: 配置告警消息接受者信息，例如常用的email、wechat、slack、webhook 等消息通知方式。
• inhibit_rules:告警抑制规则，当警报发出后，停止重复发送由此警报引发其他错误的警报的机制。上面的设置指的是将’critical’级别的告警发生时会抑制此警报发出的’warning’ 级别的告警。且已发送的告警与新产生的告警中的equal标签相同，则启动抑制机制停止向接收器发送通知。

重启alertmanager:

[root@prometheus ~]# cd alertmanager-0.21.0.linux-amd64  
[root@prometheus alertmanager-0.21.0.linux-amd64]# ./alertmanager  

过一会收到了QQ邮箱告警:

告警解决了：

6、屏蔽某条已经产生的告警

10、在alertmanager web页面进行屏蔽
点击New Slience

填写如下内容：屏蔽组名为alertname值为hosttradingvolume的告警信息。

Create之后可以看到alertmanager主界面已经没有此类告警信息了：

之后也没有邮件提醒了。