alertmanager高可用集群需配置对齐、网络互通、状态同步三者到位：统一alertmanager.yml配置，正确设置--cluster.listen-address和--cluster.peer参数，prometheus需直连多个实例或经负载均衡推送。
搭建 Alertmanager 高可用集群，核心是让多个实例协同工作、避免单点故障，并确保告警不丢失、不重复、能联动处理（如静默同步、抑制生效、分组一致）。它不是简单起见多跑几个 Pod，而是需要配置对齐、网络互通、状态同步三者到位。
统一配置 + 一致路由规则
所有 Alertmanager 实例必须使用完全相同的 alertmanager.yml，尤其是以下部分不能有差异：
- global：SMTP/Slack/Webhook 等通知渠道参数需一致，否则同一告警在不同节点可能发向不同接收方
- route：group_by 标签、group_wait、group_interval 必须相同，否则分组逻辑分裂，导致本该合并的告警被拆成多条
- inhibit_rules 和 silence：抑制规则需全局生效，配置不一致会导致某些节点压制失败，引发告警风暴
推荐通过 Kubernetes Secret 或 Helm values.yaml 统一注入配置，避免手动修改导致偏差。
集群通信参数正确设置
每个实例启动时需明确告知“自己是谁”和“集群有哪些成员”。关键参数包括：
-
--cluster.listen-address：绑定本地集群通信端口（如
0.0.0.0:9094），必须可被其他节点 UDP/TCP 访问 -
--cluster.peer：列出至少一个其他节点地址（如
am-1:9094），建议全量互指（A→B/C，B→A/C，C→A/B） -
--web.listen-address：对外提供 UI 和 API 的端口（如
:9093），需通过负载均衡暴露给 Prometheus
注意：节点名（如 am-1）需能在集群内 DNS 或 /etc/hosts 中解析；若用 Docker 或 K8s，建议用 Service 名或 Headless Service。
Prometheus 端配置多目标推送
Prometheus 不会自动发现 Alertmanager 集群，需显式配置多个目标。有两种常用方式：
-
直连多个实例：在
prometheus.yml的alerting.alertmanagers下写入全部地址：- static_configs:<br> - targets: ['am-1:9093', 'am-2:9093', 'am-3:9093']
- 经负载均衡代理：用 Nginx/HAProxy 做 TCP 层转发（非 HTTP），后端指向三个 Alertmanager 实例，Prometheus 只配一个 VIP 地址
无论哪种方式，Prometheus 发送的每条告警都会被所有健康节点接收——Alertmanager 集群内部靠 Gossip 协议自动去重和状态同步，无需外部协调。
验证联动是否生效
集群搭好后，重点验证三项联动能力：
-
静默同步：在任意一个 Alertmanager Web UI（
/#/silences）创建静默，几秒内其他节点 UI 应显示相同静默项 -
告警去重：触发一条告警，检查各实例的
/api/v2/alerts返回结果应一致，且通知日志中仅有一条发送记录（即使三个实例都收到） -
故障接管：停掉一个实例，观察剩余节点是否继续正常收告警、发通知、响应 UI 请求；Prometheus 日志不应出现大量
connection refused
若静默不同步，大概率是集群端口不通或节点名解析失败；若告警重复发送，需检查 storage.path 是否各自独立（严禁共享存储），以及 --cluster.* 参数是否遗漏。
