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

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

在Prometheus中，还可以通过Group（告警组）对一组相关的告警进行统一定义。当然这些定义都是通过YAML文件来统一管理的。

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

Alertmanager特性

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

分组

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

例如，当集群中有数百个正在运行的服务实例，并且为每一个实例设置了告警规则。假如此时发生了网络故障，可能导致大量的服务实例无法连接到数据库，结果就会有数百个告警被发送到Alertmanager。 而作为用户，可能只希望能够在一个通知中中就能查看哪些服务实例收到影响。这时可以按照服务所在集群或者告警名称对告警进行分组，而将这些告警内聚在一起成为一个通知。 告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。

抑制

抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。 例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。 抑制机制同样通过Alertmanager的配置文件进行设置。

静默

静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。

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

下载安装

[root@prometheus software]# wget https://github.com/prometheus/alertmanager/releases/download/v0.28.1/alertmanager-0.28.1.linux-amd64.tar.gz
[root@prometheus software]# tar -zxvf alertmanager-0.28.1.linux-amd64.tar.gz
[root@prometheus software]# mv alertmanager-0.28.1.linux-amd64 /usr/local/alertmanager

Systemctl

[root@prometheus software]# vim /etc/systemd/system/altermanager.service
  [Unit]
  Description=https://prometheus.io

  [Service]
  Restart=on-failure
  ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

  [Install]
  WantedBy=multi-user.target
[root@prometheus software]# systemctl daemon-reload
[root@prometheus software]# systemctl enable altermanager
[root@prometheus software]# systemctl start altermanager
[root@prometheus software]# systemctl status altermanager

@告警通知

@告警恢复

templates: # # 模板

• ‘/usr/local/alertmanager/alert.tmp’

route：用来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的入口点。

另外，根路由需要配置一个接收器(receiver)，用来处理那些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警），即缺省

接收器。告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。因为在route中

continue默认为false，如果continue为true，则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route，则该告警将从其上一级(

匹配)route或者根route发出（按最后匹配到的规则发出邮件）。查看你的告警路由树，https://www.prometheus.io/webtools/alerting/routing-tree-editor/,

将alertmanager.yml配置文件复制到对话框，然后点击"Draw Routing Tree"

route: group_by: [‘alertname’] # 用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组，然后作为一个通知发送。如果想完全禁用聚合，可以设置为group_by: […] group_wait: 30s # 当一个新的告警组被创建时，需要等待’group_wait’后才发送初始通知。这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为一个通知发送。 group_interval: 2m # 当第一次告警通知发出后，在新的评估周期内又收到了该分组最新的告警，则需等待’group_interval’时间后，开始发送为该组触发的新告警，可以简单理解为，group就相当于一个通道(channel)。 repeat_interval: 10m # 告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔。 receiver: ’email’ # 配置告警消息接收者，与下面配置的对应。例如常用的 email、wechat、slack、webhook 等消息通知方式。

receivers: # 配置报警信息接收者信息。

• name: ’email’ # 警报接收者名称 email_configs:
  • to: ‘{{ template “email.to”}}’ # 接收警报的email（这里是引用模板文件中定义的变量） html: ‘{{ template “email.to.html” .}}’ # 发送邮件的内容（调用模板文件中的）

headers: { Subject: " {{ .CommonLabels.instance }} {{ .CommonAnnotations.summary }}" } # 邮件标题，不设定使用默认的即可

send_resolved: true        # 故障恢复后通知

<img src="https://static.xp.sb/images/2025/04/06/prometheus-altermanager.png" style="zoom:50%;" />

# 关联Prometheus与Alertmanager
在`Prometheus`的架构中被划分成两个独立的部分。`Prometheus`负责产生告警，而`Alertmanager`负责告警产生后的后续处理。因此`Alertmanager`部署完成后，需要在`Prometheus`中设置`Alertmanager`相关的信息。

编辑Prometheus配置文件prometheus.yml,并添加以下内容：
```shell
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

重启Prometheus服务，成功后，可以从http://<ip或域名>:9090/config查看alerting配置是否生效。