Alertmanager是Prometheus监控体系中负责告警处理的独立组件，它接收Prometheus推送过来的告警事件，完成去重、分组、抑制、静默等处理后，再通过邮件、Webhook等渠道发送出去。如果Alertmanager只部署一个实例，一旦这个实例宕机或者网络中断，所有告警都会石沉大海，等到发现问题时往往为时已晚。因此生产环境中通常以集群方式部署Alertmanager，这也是官方推荐的高可用方案。本文将从原理、配置、验证三个方面，完整讲解Alertmanager集群部署的落地过程。
Alertmanager集群的工作原理
Alertmanager的高可用设计与大多数组件不太一样。它并没有采用主从复制或者选主机制，而是采用了对等节点的Gossip协议。也就是说，集群中每个Alertmanager节点都是平等的，都完整地接收Prometheus发来的告警，节点之间通过TCP和UDP的9094端口互相传播状态信息，包括已经触发的告警、通知记录以及静默规则等。
Prometheus端的配置也比较特别：它会将告警同时发送给集群中的所有Alertmanager节点，而不是只发给其中一个节点。每个节点收到告警后，先在集群内部通过Gossip同步，确认某个节点已经发送过通知后，其他节点就不会重复发送。这样即使某个节点挂掉，剩余节点依然能正常完成告警分发，天然实现了故障转移，无需额外的心跳检测和切换脚本。
需要注意的一个特点是，Alertmanager的高可用机制依赖通知渠道的去重能力。以邮件为例，理论上存在极小概率两个节点同时判断自己该发通知，导致收到两封相同的邮件。对于不支持去重的渠道，可以在下游Webhook侧做幂等处理。官方文档也明确说明，这种设计优先保证告警不丢，宁可偶尔重复也不遗漏。
集群部署具体步骤
假设我们准备部署一个三节点的集群，机器IP分别为192.168.1.11、192.168.1.12和192.168.1.13。首先在每台机器上下载并解压Alertmanager安装包，然后编写各自的配置文件alertmanager.yml。这里以一个简单的Webhook通知为例，三个节点的业务配置完全相同：
global:
resolve_timeout: 5m
route:
receiver: 'default'
group_by: ['alertname', 'instance']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receivers:
- name: 'default'
webhook_configs:
- url: 'http://192.168.1.20:8080/alert'
接下来是关键的一步，使用集群参数启动服务。三个节点的启动命令分别如下：
# 节点一 192.168.1.11 ./alertmanager \ --config.file=alertmanager.yml \ --storage.path=/data/alertmanager \ --web.listen-address=:9093 \ --cluster.listen-address=192.168.1.11:9094 \ --cluster.peer=192.168.1.12:9094 \ --cluster.peer=192.168.1.13:9094 # 节点二 192.168.1.12 ./alertmanager \ --config.file=alertmanager.yml \ --storage.path=/data/alertmanager \ --web.listen-address=:9093 \ --cluster.listen-address=192.168.1.12:9094 \ --cluster.peer=192.168.1.11:9094 \ --cluster.peer=192.168.1.13:9094 # 节点三 192.168.1.13 ./alertmanager \ --config.file=alertmanager.yml \ --storage.path=/data/alertmanager \ --web.listen-address=:9093 \ --cluster.listen-address=192.168.1.13:9094 \ --cluster.peer=192.168.1.11:9094 \ --cluster.peer=192.168.1.12:9094
几个参数的含义需要弄清楚。--web.listen-address是Web界面和API的监听端口，默认9093，Prometheus对接的就是这个端口；--cluster.listen-address是Gossip通信的绑定地址，默认监听所有网卡的9094端口，生产环境建议显式指定内网IP；--cluster.peer用于指定要加入的集群伙伴节点，填写其他节点的9094地址即可，不需要填写自己的地址。
如果使用systemd管理服务，可以把上述参数写进启动单元文件，示例如下：
[Unit] Description=Prometheus Alertmanager After=network.target [Service] Type=simple User=prometheus ExecStart=/opt/alertmanager/alertmanager \ --config.file=/opt/alertmanager/alertmanager.yml \ --storage.path=/data/alertmanager \ --web.listen-address=:9093 \ --cluster.listen-address=192.168.1.11:9094 \ --cluster.peer=192.168.1.12:9094 \ --cluster.peer=192.168.1.13:9094 Restart=on-failure [Install] WantedBy=multi-user.target
之后执行systemctl daemon-reload和systemctl enable --now alertmanager即可完成服务托管。三台机器都启动后，观察日志中出现cluster成员同步的记录，说明集群已经初步组建完成。
Prometheus端配置与集群验证
Alertmanager集群部署好之后，还必须修改Prometheus的配置，把所有节点地址都写进alerting段，这样告警才会同时推送给每个节点：
alerting:
alertmanagers:
- static_configs:
- targets:
- '192.168.1.11:9093'
- '192.168.1.12:9093'
- '192.168.1.13:9093'
rule_files:
- 'rules/*.yml'
这里强调一点，不要在Prometheus前面再加一层负载均衡器把Alertmanager集群聚合成一个虚拟地址。前面已经分析过，Alertmanager集群依赖全量接收加节点间Gossip同步来去重，如果负载均衡把每条告警只转发给一个节点，虽然功能上也能工作，但会削弱集群对通知状态的感知能力，官方明确建议Prometheus直连所有节点。
配置完成后需要验证集群是否真正组建成功。打开任意节点的Web界面，访问http://192.168.1.11:9093，点击Status菜单查看集群状态，正常情况下能看到三个节点的信息，状态为ready。也可以通过API查看：访问http://192.168.1.11:9093/api/v2/status，返回的JSON中cluster段会列出所有peers。此外还可以做故障演练：手动停掉一个节点，触发一条测试告警，确认通知仍能正常送达；再把节点拉起来，观察它能否自动重新加入集群并同步静默状态。
常见问题与注意事项
第一个常见问题是节点之间无法组成集群。排查思路是检查9094端口的TCP和UDP连通性，Gossip通信同时使用这两种协议，云主机安全组只放行TCP是不够的。可以用nc -zv 192.168.1.12 9094结合抓包工具排查。第二个问题是节点时钟不同步，虽然Gossip对时钟要求不算苛刻，但通知时间和静默过期判断依赖系统时间，建议所有节点统一部署chrony做时间同步。
另一个容易忽视的点是通知记录的持久化。Alertmanager会把已发送的通知记录存储在--storage.path指定的目录下，如果这个目录没有持久化，节点重启后通知记录丢失，可能导致告警重复发送。生产环境务必将存储路径挂载到独立磁盘或持久卷，并在做备份时一并考虑。
最后是升级与扩容。向运行中的集群添加新节点时，新节点只需要通过--cluster.peer指向任一存量节点即可自动加入。滚动升级时建议逐个节点操作，确认节点重新加入集群且状态为ready后再处理下一个，整个过程告警链路不会中断。结合Prometheus自身的双实例采集，就能构建出一套从数据采集到告警分发全链路高可用的监控体系。
PrometheusAlertmanager集群部署修改时间：2026-09-02 11:06:59