【云原生】Prometheus整合Alertmanager告警规则使用详解

一、前言

二、Altermanager概述

2.1 什么是Altermanager

2.2 Altermanager使用场景

三、Altermanager架构与原理

3.1 Altermanager使用步骤

3.2 Altermanager工作机制

3.3 Altermanager在Prometheus中的位置

四、Altermanager部署与接入Prometheus

4.1 Altermanager部署过程

4.1.1 获取安装包

4.1.2 安装包解压

4.1.3 启动alertmanager服务

4.1.4 访问Altermanager

4.1.5 Altermanager核心配置文件介绍

4.2 Altermanager接入Prometheus

4.2.1 配置alert target

4.2.2 配置Altermanager监控指标

4.2.3 访问Prometheus

4.3 监控node_exporter

4.3.1 创建rule（规则）目录和规则文件

4.3.2 修改prometheus.yml

4.3.3 重启Prometheus

4.3.4 测试告警规则

五、Alertmanager配置告警推送

5.1 Alertmanager配置邮箱告警通知

5.1.1 注册QQ邮箱

5.1.2 开启SMTP服务

5.1.3 配置alertmanager.yml

5.1.4 重载配置文件

5.1.5 效果验证

5.2 Alertmanager配置钉钉告警通知

5.2.1 配置钉钉机器人

5.2.2 获取钉钉webhook插件包

5.2.3 修改配置文件信息并启动服务

5.2.4 使用docker的方式安装

5.2.5 修改altermanager的配置

5.2.6 重启altermanager服务

5.2.7 补充说明

六、写在文末

一、前言

在之前的文章中我们介绍了Prometheus的搭建与使用，以及如何配置监控常用的中间件，并基于Grafana对监控的服务指标信息进行可视化展现，接下来问题来了，人们不可能24小时都盯着展示的大屏看数据，是否有某种机制，或者某种方式，比如可以配置某项指标的阈值，一旦当这个指标达到阈值时，能通过一些通知方式将告警信息主动推送给相应的人员呢？这就是本文要分享的关于AlterManager的使用。

二、Altermanager概述

2.1 什么是Altermanager

Alertmanager是Prometheus监控系统的一个重要组成部分，主要用于处理由Prometheus服务器生成的警报。虽然Prometheus本身能够检测到指标阈值的违反情况并触发警报，但它并不直接负责警报的后续处理和通知。这就是Alertmanager介入的地方。具体来说，其主要功能特性如下：

警报接收与处理：Alertmanager接收来自Prometheus的警报，并对其进行进一步的处理，包括去重、分组、抑制和静默等；
去重：同一警报可能会因为网络问题或Prometheus的重试机制而被重复发送，Alertmanager会确保每个警报只被处理一次；
分组：Alertmanager可以将类似的警报合并在一起，减少警报的总数量，避免在大量警报出现时造成通知过载；
抑制与静默：Alertmanager支持设置抑制规则，在一定时间内不发送重复的警报，以及静默规则，用于在特定时间或条件下暂停警报的发送，例如在预定的维护窗口期间；
路由：警报可以按照定义好的路由规则被发送到不同的接收者，这使得可以针对不同的警报类型或严重级别选择合适的响应团队；
通知：Alertmanager支持多种通知渠道，包括电子邮件、短信、Slack、Telegram、Webhooks等，以确保警报可以快速准确地送达相关人员；

2.2 Altermanager使用场景

Alertmanager 在多种场景下都能发挥关键作用，特别是在企业级应用和云原生环境中。以下是 Alertmanager 的一些典型使用场景：

生产环境监控：
- Alertmanager 可与 Prometheus 或其他监控系统集成，用于实时监控生产环境中的各项指标，如服务器负载、应用程序性能、数据库状态等。当检测到异常或指标超过预设阈值时，Alertmanager 能及时发送预警通知，帮助运维人员迅速定位和解决问题，确保业务连续性和系统稳定性。
自动化运维：
- 通过 Alertmanager，运维团队可以建立自动化工作流，比如，在检测到某个服务故障后自动重启服务，或者在资源利用率过高时自动扩展资源。这种自动化响应可以减少人工干预的需求，提升系统自愈能力。
事件响应和管理
- 当系统发生故障时，Alertmanager 可以将警报按严重程度和类型分发给相应的团队成员，确保每个人收到与其职责相关的信息。这样可以加快事件响应速度，减少平均修复时间（MTTR），并有助于事件的高效管理。
合规性和审计：
- 在金融、医疗等对数据安全有严格要求的行业，Alertmanager 可以用于监控合规性指标，如数据泄露风险、访问控制违规等。一旦发现潜在的合规问题，立即通知合规团队采取行动。
用户体验监控：
- 对于面向用户的在线服务，Alertmanager 可以监控用户请求的延迟、错误率等指标，确保良好的用户体验。一旦检测到可能影响用户体验的问题，可以立即通知前端或后端开发团队进行优化。
容量规划：
- Alertmanager 可以帮助监控资源使用趋势，预测未来需求。如果发现资源接近耗尽，可以提前发出警告，以便进行容量规划和资源分配调整。
节假日和非工作时间的警报管理
- Alertmanager 支持设置警报抑制规则，可以根据时间表自动开启或关闭警报，避免在非工作时间产生不必要的警报，同时确保紧急警报仍然能够得到处理。
第三方服务集成
- Alertmanager 可以通过 Webhooks 或其他接口与第三方服务（如 PagerDuty、OpsGenie、钉钉、企业微信等）集成，将警报信息发送到团队常用的消息平台，提高警报的可见性和响应速度。

通过以上场景，可以看到 Alertmanager 是一个非常灵活且强大的工具，它能够适应不同规模和类型的组织的监控需求，有效提升系统的监控效率和运维管理水平。

三、Altermanager架构与原理

3.1 Altermanager使用步骤

Altermanager在生产使用时，主要分为下面几步：

部署Alertmanager；
配置告警接收人；
配置Prometheus与Alertmanager通信；
在Prometheus中创建告警规则；
配置生效并触发告警规则；

3.2 Altermanager工作机制

如下是Alertmanager的工作原理图：

Prometheus发出告警时主要分两步：

Prometheus服务器按告警规则（rule_files配置块），将报警信息发送至Alertmanager（即告警规则是在Prometheus上定义的）；
Alertmanager 接收并管理这些报警，包括去重（Deduplicating）、分组（Grouping）、沉默（silencing），抑制（inhibition），聚合（aggregation），最终通过电子邮件发出通知，对呼叫通知系统，以及即时通讯平台，将告警通知路由（route）给对应联系人。

事实上，在Alertmanager 的内部处理过程中远比这两步要复杂，为了深入了解原理，下面是更详细的处理过程：

警报接收
- Alertmanager 从 Prometheus server 接收警报。当 Prometheus 中定义的警报规则被触发时，Prometheus 会生成警报并发送给 Alertmanager。
警报去重
- Alertmanager 会对接收到的警报进行去重处理，避免同一警报被多次处理或通知，这是通过检查警报的标签组合来实现的。
警报分组
- Alertmanager 能够将具有相似标签的警报进行分组，这样可以减少警报数量，避免重复信息，并且使得警报更加易于管理。
警报抑制
- 根据配置，Alertmanager 可以抑制某些警报，防止在特定情况下警报的过度通知。例如，在大规模故障时，可能会抑制较低优先级的警报。
警报静默
- 用户可以设置静默规则，用来临时忽略特定警报，通常在计划的维护窗口期间使用。
警报状态跟踪：
- Alertmanager 会跟踪警报的状态，包括警报是否已被解决。当 Prometheus 发现警报条件不再满足时，它会发送一个状态为“resolved”的警报给 Alertmanager。
警报路由：
- Alertmanager 使用路由规则来决定警报应该发送给哪些接收者。这些规则可以根据警报的标签和状态来确定警报的接收者。
警报通知：
- 根据路由规则，Alertmanager 会将警报发送给指定的接收者。接收者可以是电子邮件、短信、Slack、PagerDuty、钉钉、企业微信等。
警报恢复确认：
- Alertmanager 在一段时间内未接收到 Prometheus 的警报更新，会自动将警报状态设为“恢复”（resolved），这个时间间隔可以在配置文件中设置。
用户交互：
- Alertmanager 提供了一个用户界面和 API，允许管理员查看警报状态、管理静默规则、查询警报历史记录等。

通过上面的步骤不难看出，Alertmanager 整个工作流程的设计目的是为了提高警报的可靠性、减少警报噪声、确保警报的及时通知以及提供有效的警报管理手段。通过上述流程，Alertmanager 成为了 Prometheus 监控体系中不可或缺的一部分，帮助用户更好地理解和应对监控系统的警报。

3.3 Altermanager在Prometheus中的位置

如下是关于Prometheus的整体架构图，Altermanager位于右上侧，简单来说，与Prometheus集成之后，一旦Prometheus收集到来自监控主机的指标信息满足告警规则，就会将其push到Altermanager。

具体来说如下所示：

告警能力在Prometheus架构中被划分为两个部分，在上图中有所展示，通过在Prometheus配置文件中定义AlertRule（告警规则），Prometheus会周期性的进行告警规则计算，如果满足告警规则触发条件，就会向Altermanager发送告警信息。

Altermanager作为一个独立组件，负责接收处理来自Prometheus Server（也可以是其他客户端程序）的告警信息。接收到之后，Altermanager可以对这些告警信息进一步的处理，比如收到大量的重复告警信息时能够消除重复告警，同时对告警信息进行分组并且路由到正确的通知方。

同时，Prometheus内置了对邮件，Slack等多种通知方式的支持，还支持与Webhook的集成，从而支持更多的定制化场景，比如目前还支持钉钉，这样用户就可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警通知信息，同时，Altermanager还提供了静默告警和告警抑制功能对钉钉的告警行为进行优化。

四、Altermanager部署与接入Prometheus

通过上面的介绍初步了解了Altermanager的基本理论，接下来通过实际操作演示如何部署Altermanager服务，以及如何接入Prometheus进行使用。

4.1 Altermanager部署过程

参考下面的操作步骤

4.1.1 获取安装包

安装包下载地址：https://prometheus.io/download/

可以直接在服务器上，使用下面的命令下载：

wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz

4.1.2 安装包解压

使用下面的命令解压安装包

tar -zxvf alertmanager-0.27.0.linux-amd64.tar.gz

4.1.3 启动alertmanager服务

进入安装包目录，使用下面的命令后台启动

cd cd alertmanager-0.27.0.linux-amd64/

# 前台启动
./alertmanager --config.file=alertmanager.yml

# 后台启动alertmanager,并且重定向输入日志到当前目录的alertmanager.out
nohup ./alertmanager --config.file=alertmanager.yml >> nohup.out 2>&1 &

4.1.4 访问Altermanager

访问：http://IP:9093/，默认端口为 9093，效果如下

同时，也提供了metrics的指标监控端点，如果访问 IP:9093/metrics，可以看到下面的指标信息，通过这个指标监控的端点，可以在后续接入Prometheus进行指标监控时使用

4.1.5 Altermanager核心配置文件介绍

Altermanager主要负责对Prometheus产生的告警进行统一处理，因此在Altermanager的配置中一般包含下面几个主要部分：

核心参数说明：

全局配置（global）：
- 用于定义一些全局的公共参数，例如全局SMTP配置，Slack配置等内容；
模板（templates）：
- 用于定义通知告警时的模板，例如HTML模板，邮件模板等；
告警路由（route）:
- 根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：
- 接收人是一个抽象概念，它可以是一个邮箱，也可以是微信、Slack或Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：
- 合理设置抑制规则，可以减少垃圾告警的产生；

4.2 Altermanager接入Prometheus

4.2.1 配置alert target

Altermanager与Prometheus集成也很简单，只需要在Prometheus的配置文件中稍改一下配置即可，找到Prometheus的yml文件，如下，只需要放开注释即可，默认是本机的Altermanager，如果是远程部署的Altermanager，更改为相应的IP即可，这一步是为了后续通过Prometheus将告警规则push到Altermanager；

4.2.2 配置Altermanager监控指标

像之前配置node_exporter那样，再在Prometheus的yml中添加一个Altermanager的job的配置，如下：

注意：以上配置完成后需要重启Prometheus

4.2.3 访问Prometheus

访问Prometheus控制台，可以看到Altermanager就纳入Prometheus进行指标监控了

4.3 监控node_exporter

在之前的文章中我们介绍了node_exporter以及集成到Prometheus监控本机内存等指标信息，现在假如说使用node_exporter检测到机器的某些指标达到了阈值，需要进行告警，在这种情况下就可以利用Altermanager的告警功能进行集成和配置，参考下面的步骤进行操作；

4.3.1 创建rule（规则）目录和规则文件

prometheus.yml同目录下新建node.yml（文件名称和可以自行修改）

node.yml配置文内容参考如下：

groups:
- name: node_exporter_alert_rule
  rules:

  - alert: PrometheusTargetMissing
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: 服务器宕机 (instance {{ $labels.instance }})
      description: "服务器宕机，或者node exporter未启动\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

  - alert: HostOutOfDiskSpace
    expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 5 and ON (instance, device, mountpoint) node_filesystem_readonly == 0
    for: 10s
    labels:
      severity: warning
    annotations:
      summary: 主机磁盘空间不足 (instance {{ $labels.instance }})
      description: "主机磁盘空间不足 (剩余 < 10% )\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

  - alert: HostHighCpuLoad
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80
    for: 0m
    labels:
      severity: warning
    annotations:
      summary: CPU使用率过高！ (instance {{ $labels.instance }})
      description: "CPU使用率超过 > 80%\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

  - alert: HostOutOfMemory
    expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: 内存使用率过高 (instance {{ $labels.instance }})
      description: "内存使用率过高 (剩余< 10% )\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

以上是列举了常用的几个关于主机相关的监控规则，比如内存使用率过高，主机磁盘空间等，更多的规则可以参阅相关的资料在这里进行配置即可；

在告警规则文件中，我们可以将一组相关的规则配置定义在一个group下，在每一个group中可以定义多个告警规则，对于一条具体的告警规则来说，主要由下面几部分组成：

alert：指定告警规则名称；
expr：基于PromQL表达式的告警触发条件，用于计算是否时间序列满足该条件；
for：评估等待时间，可选参数，用于表示只有当触发条件持续一段时间后才发告警。而在等待期间，新产生告警的状态为pending；
labels：自定义标签，允许用户指定要附加到告警上的一组附加标签；
annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字，annotations的内容在告警产生时会一同作为参数发送到Altermanager；

4.3.2 修改prometheus.yml

在Prometheus配置文件中添加下面信息，将上述的规则文件进行加载（当然，也可以通过通配符的方式进行配置）：

rule_files:
   - "node.yml"
   #- "second_rules.yml"

为了能让Prometheus启用自定义的告警规则，需要在Prometheus的全局配置文件中通过rule_files指定一组告警规则文件的访问路径，Prometheus启动的时候就会自动扫描这些规则路径下规则文件中定义的内容，并且根据这些规则计算是否向外发送通知；

4.3.3 重启Prometheus

重启Prometheus服务，然后再次进入到Prometheus的控制台，在Alert菜单下，就能看到上面的配置那几个规则信息了

展开其中的某一项，可以看到规则的详细信息，和配置文件中的是一致的

补充说明：

在上述的界面展示中，出现了3个状态，INACTIVE，Pending，Firing ，这三个状态在下面的实际操作中会得到体现，表示被监控的服务指标满足了告警规则时的不同状态的切换。

4.3.4 测试告警规则

如何验证上述配置的告警规则是否生效呢？做第一个实验，手动关闭node_exporter服务：

ps -ef|grep node_exporter
kill -9 28634

Prometheus首次检测到满足触发的条件后，由于告警规则中设置了1分钟（for:1m）的等待时间，告警状态从INACTIVE，变为Pending，如下图所示：

kill之前

一分钟之后，如果告警条件持续满足，告警状态将从Pending变为Firing，并且会将告警信息推送给Alertmanager，如下图所示：

此时再次进入到Alertmanager的控制台界面上，可以看到界面上展示出了正在告警的信息

再次启动node-exporter服务，状态过一会儿就又切换回去了

五、Alertmanager配置告警推送

通过上面的操作，可以通过Alertmanager结合Prometheus对监控的指标信息进行规则的预警，事实上，在实际应用中，运维人员希望达到的目的是，当告警规则被触发的时候，能够及时以某种方式通知到相应的人员，才能第一时间对事件现场进行响应和处理，接下来演示下如何配置告警的消息推送。

5.1 Alertmanager配置邮箱告警通知

以QQ邮箱为例进行说明

5.1.1 注册QQ邮箱

如果没有的话可以提前注册一个，略

5.1.2 开启SMTP服务

通过qq邮箱的设置，开启SMTP服务，并获取下图中的授权码，下文配置中会用到

5.1.3 配置alertmanager.yml

在该配置文件中配置如下信息

global:
  # 在3分钟内未收到新的相同告警，则认为告警已解决
  resolve_timeout: 3m 
 
  # QQ邮箱SMTP服务器地址和端口，通常使用465端口,SMTPS
  smtp_smarthost: 'smtp.qq.com:465'  
  
  # 从这个邮箱发送告警
  smtp_from: '你的QQ@qq.com'
  
  # 发送告警的邮箱账号
  smtp_auth_username: '你的QQ@qq.com'
  
  # 邮箱的第三方授权码，而不是普通密码
  smtp_auth_password: 'vuqmvptmxowwzdbbec'
  
  #根据你的SMTP服务器设置决定是否需要TLS加密
  smtp_require_tls: false   

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  #receiver: 'web.hook'
  receiver: 'email'

receivers:
  - name: 'email'
    email_configs:
    - to: '你的QQ@qq.com'
      send_resolved: true

#抑制规则
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

5.1.4 重载配置文件

重启Alertmanager服务，重启完成后，再次进入Alertmanager页面，通过status菜单可以看到，上述配置得邮箱信息就展示出来了

5.1.5 效果验证

仍然以上面配置的node-exporter为例，我们关闭该服务，理论上在1分钟之后Prometheus会检测到服务的宕机信息从而满足触发告警规则条件，从而向Alertmanager推送告警信息，上面配置了邮箱之后，Alertmanager就能将信息发送至接收的邮箱中；

将node-exporter服务kill掉之后，等待1分钟，可以看到node_exporter配置的告警规则被触发，状态也变成了Pending；

同时alertmanager控制台也输出了相应的信息

此时进入个人的QQ邮箱，可以看到一封告警通知邮件

关于邮件的告警推送，也可以采用自定义邮件模板进行配置，网上关于这块的资料也比较多，基于上面的配置简单做下调增即可

5.2 Alertmanager配置钉钉告警通知

接下来演示如何将告警通知通过钉钉进行消息推送

5.2.1 配置钉钉机器人

创建钉钉群，找到群设置中的机器人

点击添加机器人

选择自定义webhook

配置如下信息

注意拷贝上面的Webhook地址和下面的加签信息，后面配置中会用到；

点击完成然后就可以看到，机器人已经创建完成

5.2.2 获取钉钉webhook插件包

alertmanger必须通过webhoo插件才能将告警发送到钉钉/微信/飞书，因此，需要先安装webhook插件，安装方式有二进制、docker和源码，这里直接运行二进制文件

webhook插件官方地址：GitHub - timonwong/prometheus-webhook-dingtalk: DingTalk integration for Prometheus Alertmanager

下载插件

wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-arm64.tar.gz

解压插件安装包

tar xf prometheus-webhook-dingtalk-2.1.0.linux-arm64.tar.gz

修改目录名称

mv prometheus-webhook-dingtalk-2.1.0.linux-arm64 prometheus-webhook-dingtalk

5.2.3 修改配置文件信息并启动服务

进入上述webhook的目录，修改yml配置文件，配置信息如下，这里可以暂时先配置一个webhoo即可，其他的可以暂时注释掉

最后使用下面的命令进行启动

./prometheus-webhook-dingtalk --config.file=./config.yml --web.enable-ui &

5.2.4 使用docker的方式安装

如果仍然觉得使用上面插件包的方式弄起来麻烦，可以使用下面的docker-compose的方式做；

创建一个config.yml配置文件

配置如下内容，webhook的信息改为你自己的即可

targets:
  webhook1:
    url: https://oapi.dingtalk.com/robot/send?access_token=aa06a9c58dfa03080c46cd243f3e81560e43d66da434d0a84ecbe2954bc58c
    secret: SEC85684de209427ba29a4d20541e86b62520068ffb3fef2dfca91af2485627c3

创建docker-compose.yml文件

配置如下内容

version: '3.3'
services:
  webhook: 
    image: timonwong/prometheus-webhook-dingtalk:v2.1.0
    container_name: prometheus-webhook-dingtalk
    ports: 
      - 8060:8060
    command: 
      - '--config.file=/etc/prometheus-webhook-dingtalk/config.yml'
    volumes: 
      - /usr/local/soft/pro/prometheus-webhook-dingtalk/config.yml:/etc/prometheus-webhook-dingtalk/config.yml  
      - /etc/localtime:/etc/localtime:ro

启动docker服务

使用docker-compose命令启动

docker-compose up -d

使用docker命令检查下容器是否启动

访问8060端点，访问地址：IP:8060，浏览器看到下面的效果说明钉钉的webhook插件服务已经可以使用

5.2.5 修改altermanager的配置

进入altermanager安装目录，找到alertmanager.yml，配置钉钉的webhook信息，如下：

5.2.6 重启altermanager服务

重启之后，模拟5.1中的操作，我们将node_exporter服务进行手动kill，在Prometheus上面可以看到如下信息

等待一分钟之后，由于满足了告警规则的触发条件，此时将告警信息推送到了钉钉的webhook地址，然后再在钉钉群中就能收到通知信息了，如下：

5.2.7 补充说明

上面总结来说做了两个示例演示，一个是通过node_exporter的服务启动和宕机模拟，验证是否能够正常触发告警规则，然后，再通过将告警规则中配置的信息，以邮件或钉消息的方式进行推送，基于此，如果在实际项目中进行应用，只需要参照类似的模式，先定义待监控的指标告警规则，然后配置告警规则被触发之后推送到指定的通知服务，或者webhook地址即可。