开发笔记:Prometheus监控运维实战十：告警管理

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Prometheus监控运维实战十：告警管理相关的知识，希望对你有一定的参考价值。

在上篇文章中，我们学习了Prometheus告警规则的配置，但由于其不提供告警发送功能，我们只能在UI界面查看到相关的告警情况。在Prometheus架构中，告警管理功能主要通过Alertmanager来完成，本文将接着上篇，讲解通过Alertmanager来实现警报的发送与管理 。

Alertmanager简介

Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持通过Webhook的方式接入企业微信、钉钉等国内IM工具。

Alertmanager除了提供基本告警通知能力以外，还具有以下几个特点：

1. 分组

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

例如，当一台宿主机上运行着数十个虚拟机，如果机器发生网络或硬件故障，运维人员可能收到数十个告警，包括物理机与上面的所有虚拟机。而逐个查看这些故障本身是个耗时的工作，也容易导致对主要问题的忽略。

作为告警接收人，可能只希望能够在一个通知中就能查看到受影响的实例信息，这时可以按照告警名称或所有宿主机对告警进行分组，而将这些告警合并到一个通知中查收。

告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。

2. 抑制：

抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。

例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。

抑制机制同样通过Alertmanager的配置文件进行设置。

3. 静默：

静默提供了一种简单的方法对特定的告警在特定时间内进行静音处理，它根据标签进行匹配。如果Alertmanager接收到的告警信息符合静默的配置，它将不会发送告警通知。静默功能适合在机器进行维护等场景下，暂时屏蔽告警通知。

静默设置需要在Alertmanager的Wer页面上进行设置。

安装部署

下载安装包并解压

$ wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
$ tar -xvf alertmanager-0.21.0.linux-amd64.tar.gz

拷贝文件到bin目录 

$ cd alertmanager-0.21.0.linux-amd64
$ sudo cp alertmanager /usr/local/bin/
$ sudo cp amtool /usr/local/bin/

注：amtool是一个Alertmanager管理工具，支持用命令行方式进行管理。

$ alertmanager --version
alertmanager, version 0.21.0 (branch: HEAD, revision: 4c6c03ebfe21009c546e4d1e9b92c371d67c021d)
build user: root@dee35927357f
build date: 20200617-08:54:02
go version: go1.14.4

配置介绍

Alertmanager与Prometheus  Server一样，也是通过yml格式的配置文件进行配置。下面是一个基本的配置文件模板：

global:
resolve_timeout: 3m
smtp_smarthost: \'localhost:25\'
smtp_from: \'devops@example.com\'
smtp_require_tls: false

templates:
- \'/etc/alertmanager/template/*.tmpl\'
route:
receiver: \'admin\'
group_by: [\'alertname\']
group_wait: 20s
group_interval: 10m
repeat_interval: 3h

receivers:
- name: \'admin\'
email_configs:
- to: \'admin@example.com\'

该配置文件总共定义了四个模块，global、templates、route和receivers。

global 

用于定义Alertmanager的全局配置。

在示例中我们只配置几个参数，其中resolve_timeout定义持续多长时间未接收到告警标记后，就将告警状态标记为resolved。而smtp_smarthost指定SMTP服务器地址，smtp_from定义了邮件发件的的地址，smtp_require_tls配置禁用TLS的传输方式。

templates

用于指定告警通知时的模板，如邮件模板等。

由于Alertmanager的信息可以发送到多种接收介质，如邮件、Slack等，我们通常需要能够自定义警报所包含的信息，这个就可以通过模板来实现。

限于篇幅原因，相关模板的配置方式本文不做介绍，有兴趣的朋友可上官网查看：https://prometheus.io/docs/alerting/latest/notifications/。

route

用于定义Alertmanager接收警报的处理方式，根据规则进行匹配并采取相应的操作。

路由是一个基于标签匹配规则的树状结构，所有的告警信息都会从配置中的顶级路由(route)进入路由树。从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收者发送告警。在示例配置中只定义了顶级路由，并且配置的接收者为admin，因此，所有的告警都会发送给到admin的接收者。

group_by用于定义分组规则，前面讲过Alertmanager支持告警分组功能，这里使用告警名称做为规则，满足规则的告警将会被合并到一个通知中；group_wait配置分组等待的时间间隔，在这个时间内收到的告警，会根据前面的规则做合并；group_interval定义相同group间发送告警通知的时间间隔；如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。

receivers
用于定义相关接收者的地址信息。

由于我们示例配置是邮件告警的方式，这里email_configs参数配置相关的邮件地址信息，另外还支持wechat_configs、webhook_configs等方式。

启动Alertmanager

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

$ alertmanager --config.file alertmanager.yml --storage.path /data/alertmanager/ &

启动完成后，打开浏览器，访问http://$IP:9093，可看到UI界面

Prometheus关联Alertmanager

Prometheus的配置文件中，alerting模块用于配置Alertmanager地址。当配置完成后，Prometheus会将触发告警规则的警报发送到Alertmanager。

alerting:
alertmanagers:
- static_configs:
- targets: [\'localhost:9093\']

我们可以试着将上篇文章中的cpu告警规则调低，触发Prometheus告警规则来验证配置，此处我们改为CPU使用率大于1%触发告警。

groups:
- name: node_alert
rules:
- alert: cpu_alert
expr: 100 -avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance)* 100 > 1
for: 5m
labels:
level: warning
annotations:
description: "instance: {{ $labels.instance }} ,cpu usage is too high ! value: {{$value}}"
summary: "cpu usage is too high"

在Prometheus界面可看到已成功触发告警规则

打开Alertmanager，可看到接收到的警报信息

标签路由

在前面的示例中，我们只定义了一个顶级路由，这意味着所有的告警都由admin的接收者获取。但在实际环境中，告警的需求往往要比这个来得复杂。

例如，我们需要根据资源类型，将数据库的告警发送给DBA团队，将服务器的告警发送给运维团队；或者根据告警的严重级别，普通告警发送给技术人员，严重告警还需要通知到领导层等等。

对于此类需求，我们可以使用子路由的方式来实现，这些Route支持通过标签的方式进行匹配，并发送给相关的receiver。

route:
receiver: \'admin\'
group_by: [\'alertname\']
group_wait: 20s
group_interval: 10m
repeat_interval: 3h
routes:
- receiver: \'database\'
continue: true
match_re
type: mysql|mongodb

- receiver: \'devops\'
continue: true
match:
type: server

receivers:
- name: \'admin\'
email_configs:
- to: \'admin@example.com\'

- name: \'database\'
email_configs:
- to: \'database1@example.com |database2@example.com\'

- name: \'devops\'
email_configs:
- to: \'devops1@example.com |devops2@example.com\'

在上面的这个示例中，我们配置了顶级路由，然后又根据不同的标签，定义了两个子路由和相关的接收者。其中continue的值如果为false，那么告警在匹配到第一个子节点之后就直接停止，如果continue为true，报警则会继续进行后续子节点的匹配。

对于告警信息的匹配，可以通过match和match_re进行标签的匹配，其中match匹配字符，而match_re支持正则表达式的方式。

静默告警

在某些情况下，我们可能希望对告警信息进行屏蔽，不收到相关的告警信息，例如对服务器进行关机维护、实例重启等场景。对此，Alertmanager提供了静默功能，用于处理此类需求。

静默功能的配置可以UI界面上进行，在页面上点击 "Slience"按键。

在"New Slience“页面进行配置，Matchers通过标签配置需要屏蔽的告警，如果勾上Regex，则可以在Value处使用正则表达式做匹配。在Start处填写开始时间，然后在End或Duration中填写一处即可，另外一个会自动计算出来。

配置完成后，点击 "Create”完成创建。此时点击”Sliences”，可看到已经生成的Slience。当需要提前中止该Slience时，可点击旁边的Expire红色字体，让其过期即可。