Alertmanager | 钱帅的博客

type

status

date

slug

summary

Alertmanager介绍

prometheus server仅负责生成告警提指示，具体的告警行为由另一个独立的应用程序AlertManager负责。告警指示由 Prometheus Server 基于用户提供的告警规则周期性计算生成，AlertManager接收到 Prometheus Server 发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息，Alertmanager支持Email、Slack等告警方式，也可以通过webhook接入钉钉等国内IM工具。告警的作用其实就是一句话：系统出问题了我们能及时感知到。

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

Alert的三种状态： pending：警报被激活，但是低于配置的持续时间。这里的持续时间即rule里的for字段设置的时间，该状态下不发送报警 firing：警报已被激活，而且超出设置的持续时间。该状态下发送报警 inactive：既不是pending也不是firing的时候状态变为inactive

除了基本的告警通知能力外，Altermanager还支持对告警进行去重、分组、抑制、静默和路由等功能 分组（Grouping）：将相似告警合并为单个告警通知的机制，在系统因大面积故障而触发告警潮时，分组机制能避免用户被大量的告警噪声淹没，进而导致关键信息的隐没 抑制（Inhibition）：系统中某个组件或服务故障而触发告警通知后，那些依赖于该组件或服务的其它组件或服务可能也会因此而触发告警，抑制便是避免类似的级联告警的一种特性，从而让用户能将精力集中于真正的故障所在 静默（Silent）：是指在一个特定的时间窗口内，即便接收到告警通知，Alertmanager也不会真正向用户发送告警信息的行为；通常，在系统例行维护期间，需要激活告警系统的静默特性 路由（route）：用于配置Alertmanager如何处理传入的特定类型的告警通知，其基本逻辑是根据路由匹配规则的匹配结果来确定处理当前告警通知的路径和行为

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

部署

二进制部署

官方下载地址: https://prometheus.io/download

启动服务

配置alertmanager.service启动脚本

启动alertmanager并设置为开机自启动

打开浏览器访问<ip>:9093

k8s 部署Alertmanager

要运行到 Kubernetes 集群中，首先创建一个 ConfigMap 配置文件alertmanager-config.yaml

然后配置 AlertManager 的容器，直接使用一个 Deployment 来进行管理即可，对应的 YAML 资源声明如下

这里我们将上面创建的 alert-config 这个 ConfigMap 资源对象以 Volume 的形式挂载到 /etc/alertmanager 目录下去，然后在启动参数中指定了配置文件 --config.file=/etc/alertmanager/config.yml，然后我们可以来创建这个资源对象：为了可以访问到 AlertManager，同样需要我们创建一个对应的 Service 对象：

AlertManager 的容器启动起来后，我们还需要在 Prometheus 中配置下 AlertManager 的地址，让 Prometheus 能够访问到 AlertManager，在 Prometheus 的 ConfigMap 资源清单中添加如下配置：

配置详解

Alertmanager主要负责对Prometheus产生的告警进行统一处理，在Alertmanager配置中一般会包含以下几个主要部分： 全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容； 模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等； 告警路由（route）：根据标签匹配，确定当前告警应该如何处理； 接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用； 抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生

配置文件内容如下，供参考

修改好配置文件后，可以使用amtool工具检查配置

启动alertmanager

页面访问ip:9093查看AlertManager的WEB UI页面

浏览器访问web页面，可以看到 alertermanager 配置文件

global全局配置

global全局配置用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容

告警路由

告警路由，告警内容从这里进入，根据标签匹配，寻找自己应该用那种策略发送出去

Alertmanager 会将接收到的报警规则按照 group_by 进行分组。每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re)，每一个路由都可以定义自己的接收人以及匹配规则。默认情况下，告警进入到顶级route后会遍历所有的子节点，直到找到最深的匹配route，并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。

其中告警的匹配有两种方式可以选择。一种方式基于字符串验证，通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。

一个完善的告警系统，告警路由通常是非常复杂的，为了便于运维人员配置，prometheus官方开发了一个路由配置树工具。https://www.prometheus.io/webtools/alerting/routing-tree-editor

配置举例：告警分组功能的实现

默认情况下所有的告警都会发送给管理员default-receiver，因此在Alertmanager的配置文件的根路由中，对告警信息按照集群以及告警的名称对告警进行分组。如果告警是来源于数据库服务如mysql或者pgsql，此时则需要将告警发送给相应的数据库管理员(dba)。这里定义了一个单独子路由，如果告警中包含service标签，并且service为mysql或者pgsql则向dba-pager发送告警通知。由于这里没有定义group_by等属性，这些属性的配置信息将从上级路由继承，dba-pager将会接收到按cluser和alertname进行分组的告警通知。而某些告警规则来源可能来源于开发团队，这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下，定义单独子路由用于处理这一类的告警通知，如果匹配到告警中包含标签team，并且team的值为dev，Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常，开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。

配置举例：告警分级功能的实现

在每条告警配置的标签中添加severity配置，有三种等级，分别为warning、critical和emergency。严重等级依次递增。不论收到那种等级的告警，都会邮件通知给默认的管理员default-receiver。当告警等级为critical时，比较严重的告警，发送短信通知，每2h重复发送一次，直到问题解决。当告警等级为emergency时，特别严重的告警，打电话通知，每1h重复发送一次，直到问题解决

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

然后我们对其进行分组，然后观察发现消息以组的形式发送，每个组中包含了多个监控告警

我们知道，在Prometheus中每个指标都会有标签，如下图框出来的部分

AlertManager 的告警分组是基于 PromQL 查询结果中的标签信息进行的。分组的依据是标签的 key 和 value，当多条告警的 key 和 value 完全相同时，它们会被归为同一组。如下我们定义了标签namespace的value和标签altername的value相同的告警都归入到一组中

点击+号展开，能看到该组下的告警详情，比如我们这一共有4个告警

查看告警邮件能看到该告警信息是以组的形式发送的，这个组中一共有4条告警

告警抑制

抑制是指当某次告警发出后，可以停止重复发送由此告警引发的其他告警的机制，比如现在有一台服务器宕机了，上面跑了很多服务都设置了告警，那么肯定会收到大量无用的告警信息，这个时候抑制就非常有用了，可以有效的防止告警风暴。要使用抑制规则，需要在 Alertmanager 配置文件中的 inhibit_rules 属性下面进行定义，每一条抑制规则的具体配置如下：

当已经发送的告警通知匹配到 target_match 和 target_match_re 规则，当有新的告警规则如果满足 source_match 或者 source_match_re 的匹配规则，并且已发送的告警与新产生的告警中 equal 定义的标签完全相同，则启动抑制机制，新的告警不会发送。例如当集群中的某一个主机节点异常宕机导致告警 NodeDown 被触发，同时在告警规则中定义了告警级别为 severity=critical，由于主机异常宕机，则该主机上部署的所有服务会不可用并触发报警，根据抑制规则的定义，如果有新的告警级别为 severity=critical，并且告警中标签 instance 的值与 NodeDown 告警的相同，则说明新的告警是由 NodeDown 导致的，则启动抑制机制停止向接收器发送通知。

现在我们来创建一个报警规则，进行演示

可以看到，当前我们系统里面的告警有三条，其中master节点报警有两条，node1节点报警有一条

现在我们假设来配置一个抑制规则，如果 NodeMemoryUsage 报警触发，则抑制 NodeLoad 指标规则引起的报警，我们这里就会抑制 master节点的告警，只会剩下 node1 节点的告警。在 Alertmanager 配置文件中添加如下所示的抑制规则：

告警级别匹配为critical严重级别，则同一个instance的warning警告级别的告警会被抑制。即只发送严重级别的告警，warning级别的告警不再发出。更新配置后，重新启动 Alertmanager 服务，可以看到只能收到 node1 节点的 NodeLoad 报警，master节点的NodeLoad报警被抑制了

告警静默

在做代码上线或者版本升级时，可以预知告警会发生，为了不让告警发出，可将此告警项在上线或升级期间不发出告警，上线或升级完成后再解除静默。这里以静默172.31.7.191节点critical级别的告警为例，172.31.7.191存在critical和info两个级别的告警。在alertmanager控制台，选择Alerts，找到172.31.7.191节点，点击后方的Slience按钮

填写静默规则创建者和说明，我们可以选择此次静默的开始时间、结束时间，最重要的是下面的 Matchers 部分，用来匹配哪些报警适用于当前的静默。比如这里我们设置如下图的标签，则表示具有这个标签的报警在 2 小时内都不会触发报警，点击下面的 Create 按钮即可创建

查看静默规则

查看钉钉告警中只有172.31.7.191节点info级别的的告警，critical级别的告警不再发出，说明静默规则已经生效

报警规则

Alertmanager 的报警规则基于 Prometheus 的表达式（PromQL）定义，当符合条件时会触发报警，并将通知发送给预定义的外部接收者。下面我们创建一个报警规则文件prometheus_rule.yaml

上面我们定义了一个名为 NodeMemoryUsage 的报警规则，一条报警规则主要由以下几部分组成： alert：告警规则的名称，用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容 expr：是用于进行报警规则 PromQL 查询语句 for：评估等待时间（Pending Duration），用于表示只有当触发条件持续一段时间后才发送告警，在等待期间新产生的告警状态为 pending。这个参数主要用于降噪，很多类似响应时间这样的指标都是有抖动的，通过指定 Pending Duration，我们可以过滤掉这些瞬时抖动，可以让我们能够把注意力放在真正有持续影响的问题上。 labels：自定义标签，允许用户指定额外的标签列表，把它们附加在告警上 annotations：指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的

对接Prometheus

AlertManager 会根据匹配规则发送告警信息，但具体的告警触发规则需要在 Prometheus 上配置。Prometheus 通过评估监控数据来判断是否满足触发告警的条件。在prometheus配置文件中，可以通过调用文件来匹配报警规则，配置文件中 rule_files 就是用来指定报警规则文件的

配置修改完后重启prometheus，查看prometheus控制台页面status → configuration页面就能看到我们修改好的配置文件

告警接收

Alertmanager 支持很多内置的报警接收器，如 email、slack、企业微信、webhook 等。Alertmanager 默认使用的通知模板可以从https://github.com/prometheus/alertmanager/blob/master/template/default.tmpl获取，这里我们使用的是基于模板字符串，直接在 Alertmanager 的配置文件中使用模板字符串，如下所示：

邮件告警

目前除了使用公司邮箱不需要使用授权码登录外，像什么QQ邮箱，163邮箱，Sina邮箱等等都需要。几年之前还不用授权码的，可能是他们的安全的重视程度过高了。这篇文章来讲解如何通过qq号实现邮箱告警。所以如果你使用的是QQ邮箱那么你需要开启POP3/SMTP服务，并且获取授权码，smtp_auth_password 配置的就是授权码，而不是你qq邮箱的登录密码。下面以 QQ 邮箱为例，演示下如何开启

配置邮件告警的 Alertmanager 配置文件模板

接下来，我们需要在 Prometheus 配置 AlertManager 服务地址以及告警规则，新建报警规则文件 node_up.yaml 如下：

该 rules 目的是监测 node 是否存活，expr 为 PromQL 表达式验证特定节点 job="node_exporter" 是否活着，for 表示报警状态为 Pending 后等待 15s 变成 Firing 状态，一旦变成 Firing 状态则将报警发送到 AlertManager，labels 和 annotations 对该 alert 添加更多的标识说明信息，所有添加的标签注解信息，以及 prometheus.yml 中该 job 已添加 label 都会自动添加到邮件内容中

然后，修改 prometheus.yml 配置文件，添加 rules 规则文件，如果已经有该配置则忽略

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

我们定义的 rule 规则为监测 job="node_exporter" Node 是否活着，那么就可以停掉 node_exporter 服务来间接起到 Node Down 的作用，从而达到报警条件，触发报警规则。停止服务后，等待 15s 之后可以看到 Prometheus target 里面 node_exproter 状态为 unhealthy 状态。等待 15s 后，alert 页面由绿色 node_up (0 active) Inactive 状态变成了黄色 node_up (1 active) Pending 状态，继续等待 15s 后状态变成红色 Firing 状态，向 AlertManager 发送报警信息，此时 AlertManager 则按照配置规则向接受者发送邮件告警。

最终发送的默认报警邮件信息如下：

从上图可以看到，默认邮件模板 Title 及 Body 会将之前配置的 Labels 及 Annotations 信息均包含在内，而且每隔 5m 会自动发送，直到服务恢复正常，报警解除为止，同时会发送一封报警解除邮件。接下来，我们启动 node-exporter 来恢复服务。等待 15s 之后，Prometheus Alerts 页面变成绿色 node-up (0 active) Inactive 状态，同时也收到了报警解除邮件提醒

每次停止/恢复服务后，15s 之后才会发现 Alert 状态变化，是因为 prometheus.yml中 global -> scrape_interval: 15s 配置决定的，如果觉得等待 15s 时间太长，可以修改小一些，可以全局修改，也可以局部修改。例如局部修改 node-exporter 等待时间为 5s。

报警触发后，每隔 5m 会自动发送报警邮件(服务未恢复正常期间)，是因为 alertmanager.yml 中 route -> repeat_interval: 5m 配置决定的。

自定义邮件模板

默认发送的邮件模板，虽然所有核心的信息已经包含了，但是邮件格式内容可以更优雅直观一些，那么，AlertManager 也是支持自定义邮件模板配置的，首先新建一个模板文件 email.tmpl

修改alertmanager.yml 配置：

现在将一台服务器关机，模拟触发报警条件，查看告警邮箱

钉钉告警

我们可以通过脚本直接调用钉钉的API接口发送告警消息，但是prometheus目前还不能直接调用API接口发送告警信息给接收者，因此需要部署dingtalk插件，prometheus将告警发送给dingtalk，由dingtalk把告警信息转发给钉钉，再由钉钉把告警发送给告警接收者。告警转发流程：

下载钉钉并注册钉钉账号，建立钉钉群。注意：建钉钉群时最少三个人才可以建群。在钉钉群组中，点击右上角群设置按钮→选择智能群助手→选择添加机器人→选择添加的机器人类型→选择自定义-通过webhook介入自定义服务，然后选择添加

关键字认证

对告警机器人进行配置安全设置：勾选自定义关键词，然后在下方写入关键词，我这里定义的关键词是alertname。注意：通过关键词认证实现告警，要求在告警内容中必须有alertname关键词，否则将无法通过钉钉进行告警，因此关键词要选择告警内容中通用的字段，这里在所有告警内容中都存在alertname字段，因此选择该字段作为关键词

配置完成后，获取webhook的url地址，复制并保存，然后点击完成。如果url忘记保存，可通过以下步骤获取url地址 1、找到钉钉群智能群助手 2、点击添加机器人右侧的三角符号 3、在下方根据机器人名称找到设置的机器人，点击设置按钮即可获取webhook url地址另外，如果url泄露或者不安全，可以进行重置获取新的url地址

创建dingding-keywords.sh脚本，通过脚本发送消息进行测试，脚本内容如下：

执行shell脚本，注意：位置变量发送的内容中必须包含关键字alertname，且不能包含空格和特殊字符，否则将无法成功发送消息

查看钉钉群，可以正常接收告警消息

加签认证

通过加签的方式进行钉钉告警通知，注意保存webhook url地址和加签密钥

通过dingding-label-sign.py脚本获取认证需要的时间戳和签名

执行脚本，注意：每次执行脚本，时间戳和签名都会变化

通过dingding_secret.sh脚本发送测试消息

执行shell脚本

查看钉钉群，可以正常接收告警消息

部署webhook-dingtalk

dingtalk插件在2.0.0版本已经不支持通过指定--ding.profile参数方式启动dingtalk

github下载网址：https://github.com/timonwong/prometheus-webhook-dingtalk/releases dingtalk安装包下载链接：https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v1.4.0/prometheus-webhook-dingtalk-1.4.0.linux-amd64.tar.gz

下载dingtalk并解压

执行以下命令启动dingtalk服务

命令格式说明：

修改alertmanager配置文件

重启alertmanager服务使配置生效

配置prometheus

重启prometheus服务，重新根据规则文件判断是否发出告警。登录prometheus控制台查看告警是否发出

查看接收告警的钉钉群，是否接收到告警信息

通过配置文件方式部署webhook-dingtalk

dingtalk插件在2.0.0版本已经不支持通过指定--ding.profile参数方式启动dingtalk，但由于存在使用老版本dingtalk插件的情况，因此如果使用较新版本的dingtalk，可以使用通过配置文件方式启动dingtalk。根据dingtalk自带模板文件创建dingtalk配置文件

修改dingtalk配置文件，这里以关键字认证方式进行配置

配置说明：

创建dingtalk service文件

启动dingtalk服务

修改alertmanager配置

重启服务，查看钉钉群告警信息

alertmanager引用模板

创建存放消息模板的目录

创建自定义消息模板alertmanager-dingtalk.tmpl。注意：配置文件中的"email.to.message"要和dingtalk配置文件config.yml文件中message的text参数的值保持一致，否则将无法调用该模板

注意：文件第一行中” email.to.message”要和dingtalk配置文件中message字段保持一致

修改dingtalk配置文件，调用报警模板（这里以关键字认证方式进行配置）

重启dingtalk服务

查看钉钉群告警信息

企业微信

登录PC版企业微信官网：https://work.weixin.qq.com使用微信账号扫码进行登录

通讯录-创建部门，然后添加部门成员。创建不同部门对公司员工进行区分

选中对应部门（这里以运维部为例），点击右侧添加成员按钮，配置成员信息

选中部门，点击部门右侧按钮，在最下方可以看到运维部的部门ID为2，在alertmanager配置告警时，我们可以通过部门ID将告警发送给指定的部门

创建应用：应用管理-创建应用

2、填写应用信息（1）可以上传应用logo （2）填写应用名称（3）填写描述（4）选择告警可见范围：可根据需求选择可以查看告警的部门填写完成后，点击创建应用

使用告警机器人发送消息进行测试，看企业微信能否接收到消息

要在prometheus配置企业微信告警，要先获取对应的认证信息：企业ID、AgentID和Secret 企业ID：用于企业认证，将告警发送给不同的企业，每个企业都有唯一的企业ID AgentID：用于调用对用的应用（告警机器人） Secret：用于应用（告警机器人）的认证

获取企业ID：首页-我的企业，最下方获取企业ID

获取AgentID和Secret：首页-应用管理-最下方自建应用，找到之前设置的告警机器人，点击进入设置页面

点击Secret后的查看按钮，会弹出新窗口，然后点击发送按钮，需要在手机登录企业微信APP上查看对应的secret。注意：企业微信官方为安全起见，会将secret发送到个人企业微信APP上。登录企业微信APP（手机版或PC版均可）查看Secret

设置可信域名

如果自己练习使用需要设置可信域名，来到企业微信自建应用管理页面，点击刚刚创建好的应用

点击申请校验域名后有一条提示，请下载文件WW_verify_z0kAmKeNiJVAwe5c点击下载。然后来到阿里云官网搜索函数计算，新用户或者老用户都有免费试用，点击开通试用

开通试用后点击任务，然后创建函数

选择使用自定义运行时创建

创建完成后会自动跳转到创建的任务，把第十七行的Hello, World! 换成企业微信校验文件中的代码（从企业微信下载的“WW_verify_YfNoUbI6DrUOv1eV.txt”文件中获取）

替换好以后点击部署代码，提示部署成功后点击右侧的URL ，然后复制这个链接

最后来到企业微信自建应用管理页面，把复制的链接去掉https的前缀，点击确定即可

可信域名配好之后就可以配置可信 IP

使用登录微信后台的超管账号登录手机端企业微信app，有个消息，打开就能看到了

查看企业ID

配置alertmanager

修改alertmanager配置文件

创建微信自定义消息模板/data/alertmanager/template/message_template.templ文件

如果告警时间显示的是 UTC 时区，可以将其配置为 {{ (.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}，然后我们重启alertmanager服务，接下来将一台机器关机，然后查看告警

然后将机器启动，恢复告警

报警通知模板

一般情况下，要求告警的内容精简、易懂。默认的告警模板，告警内容比较多、比较杂、可读性不强。要想使告警内容更加易读和精简，需要自定义消息模板，对告警信息进行调整，以想要的格式发送出去。Alertmanager提供了一套基于Go的默认模板系统，这个模板我们无法更改，因此我们需要自定义一个消息模板，然后在alertmanager配置中进行调用。配置消息模板，需要根据告警内容中的字段进行编辑，配置自己想要的告警信息

官方语法介绍：https://prometheus.io/docs/alerting/latest/notifications 官方模板链接：https://github.com/prometheus/alertmanager/blob/master/template/default.tmpl 邮件模板链接：https://github.com/mailgun/transactional-email-templates