高可用性
高可用性
Alertmanager 支持配置以创建高可用集群。本文档描述了 HA 机制的工作原理、设计目标以及运维注意事项。
设计目标
Alertmanager 的 HA 实现围绕三个核心原则设计
- 统一视图和管理 - 抑制和告警可以从任何集群成员查看和管理，提供统一的运维体验
- 通过“故障开放”机制避免脑裂 - 在网络分区期间，Alertmanager 倾向于发送重复通知，而不是错过关键告警
- 至少一次投递 - 系统保证通知至少投递一次，符合故障开放的理念
这些目标优先考虑运维可靠性和告警投递，而不是严格的精确一次语义。
架构概览
Alertmanager 集群由多个 Alertmanager 实例组成，它们使用 gossip 协议进行通信。每个实例
- 独立接收来自 Prometheus 服务器的告警
- 参与点对点 gossip 网络
- 将状态（抑制和通知日志）复制到其他集群成员
- 独立处理和发送通知
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Prometheus 1 │ │ Prometheus 2 │ │ Prometheus N │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
│ alerts │ alerts │ alerts
│ │ │
▼ ▼ ▼
┌────────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ AM-1 │ │ AM-2 │ │ AM-3 │ │
│ │ (pos: 0) ├──┤ (pos: 1) ├──┤ (pos: 2) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ Gossip Protocol (Memberlist) │
└────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
Receivers Receivers Receivers
Gossip 协议
Alertmanager 使用 Hashicorp 的 Memberlist 库来实现基于 gossip 的通信。gossip 协议处理
成员管理
- 自动节点发现 - 实例可以配置已知节点列表，并自动发现其他集群成员
- 健康检查 - 定期探测以检测故障成员（默认：每 1 秒）
- 故障检测 - 标记故障成员，并允许其尝试重新加入
状态复制
gossip 层复制三种状态
- 抑制 - 创建、更新和删除操作会广播给所有节点
- 通知日志 - 发送过的通知记录，用于防止重复
- 成员变更 - 加入、离开和故障事件
状态最终一致——所有集群成员在足够的时间和网络连接的情况下会收敛到相同状态。
Gossip 稳定
当 Alertmanager 启动或重新加入集群时，它会等待 gossip“稳定”后再处理通知。这可以防止基于不完整状态发送通知。
稳定算法会等待直到
- 节点数量在 3 次连续检查中保持稳定（默认间隔：push-pull 间隔）
- 或者发生超时（通过 context 可配置）
在此期间，实例已接收并存储告警，但会推迟通知处理。
HA 模式下的通知管道
为了确保去重同时保持至少一次投递，通知管道在集群环境中运行方式有所不同
┌────────────────────────────────────────────────┐
│ DISPATCHER STAGE │
├────────────────────────────────────────────────┤
│ 1. Find matching route(s) │
│ 2. Find/create aggregation group within route │
│ 3. Throttle by group wait or group interval │
└───────────────────┬────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ NOTIFIER STAGE │
├────────────────────────────────────────────────┤
│ 1. Wait for HA gossip to settle │◄─── Ensures complete state
│ 2. Filter inhibited alerts │
│ 3. Filter non-time-active alerts │
│ 4. Filter time-muted alerts │
│ 5. Filter silenced alerts │◄─── Uses replicated silences
│ 6. Wait according to HA cluster peer index │◄─── Staggered notifications
│ 7. Dedupe by repeat interval/HA state │◄─── Uses notification log
│ 8. Notify & retry intermittent failures │
│ 9. Update notification log │◄─── Replicated to peers
└────────────────────────────────────────────────┘
HA 特有阶段
1. Gossip 稳定等待
在第一个分组通知发送之前，实例会等待 gossip 稳定。这确保了
- 抑制信息已完全复制
- 通知日志包含其他实例的最新发送记录
- 集群成员稳定
实现：peer.WaitReady(ctx)
2. 基于节点位置的等待
为了防止所有集群成员同时发送通知，每个实例会根据其在排序节点列表中的位置进行等待
wait_time = peer_position × peer_timeout
例如，3 个实例和 15 秒的节点超时
- 实例
am-1（位置 0）：等待 0 秒 - 实例
am-2（位置 1）：等待 15 秒 - 实例
am-3（位置 2）：等待 30 秒
这种错开的时间安排允许
- 第一个实例发送通知
- 后续实例查看通知日志条目
- 防止重复发送的去重
实现：cmd/alertmanager/main.go:594 中的 clusterWait()
位置通过按字母顺序对所有节点名称进行排序来确定
func (p *Peer) Position() int {
all := p.mlist.Members()
sort.Slice(all, func(i, j int) bool {
return all[i].Name < all[j].Name
})
// Find position of self in sorted list
}3. 通过通知日志进行去重
DedupStage 查询通知日志以确定是否应发送通知
// Check notification log for recent sends
entry := nflog.Query(receiver, groupKey)
if entry.exists && !shouldNotify(entry, alerts, repeatInterval) {
// Skip: already notified recently
return nil
}去重检查
- 正在触发的告警是否已更改？ 如果是，则发送通知
- 已解决的告警是否已更改？ 如果是且
send_resolved: true，则发送通知 - 重复间隔是否已到？ 如果是，则发送通知
- 否则：跳过通知（已去重）
通知日志通过 gossip 复制，因此所有集群成员共享相同的发送历史。
脑裂处理（故障开放）
在网络分区期间，集群可能会分裂成多个无法通信的组。Alertmanager 的“故障开放”设计确保告警仍能发送
场景：网络分区
Before partition:
┌────────┬────────┬────────┐
│ AM-1 │ AM-2 │ AM-3 │
└────────┴────────┴────────┘
Unified cluster
After partition:
┌────────┐ │ ┌────────┬────────┐
│ AM-1 │ │ │ AM-2 │ AM-3 │
└────────┘ │ └────────┴────────┘
Partition A │ Partition B
分区期间的行为
在分区 A（仅 AM-1）
- AM-1 将自己视为位置 0
- 等待 0 × 超时 = 0 秒
- 发送通知（来自 AM-2/AM-3 的去重信息不存在）
在分区 B（AM-2, AM-3）
- AM-2 是位置 0，AM-3 是位置 1
- AM-2 等待 0 秒，发送通知
- AM-3 查看 AM-2 的通知日志条目，进行去重
结果：发送了重复的通知（一个来自分区 A，一个来自分区 B）
这是**故意的**——Alertmanager 宁愿发送重复通知也不愿错过告警。
分区愈合后
当网络分区愈合时
- gossip 协议重新检测到所有节点
- 通知日志合并（通过类似 CRDT 的带时间戳的合并）
- 未来的通知将在所有实例之间正确去重
- 在任一分区中创建的抑制都会复制到所有节点
HA 中的抑制管理
抑制是集群中的一等复制状态。
抑制创建和更新
当在一个实例上创建或更新抑制时
- 本地存储 - 抑制存储在本地状态映射中
- 广播 - 抑制被序列化（protobuf）并通过 gossip 广播
- 接收时合并 - 其他实例接收并合并抑制
// Merge logic: last-write-wins based on UpdatedAt timestamp if !exists || incoming.UpdatedAt > existing.UpdatedAt { accept_update() } - 索引 - 抑制匹配器缓存会更新以进行快速告警匹配
抑制过期
抑制具有
StartsAt,EndsAt- 有效时间范围ExpiresAt- 何时进行垃圾回收（EndsAt + 保留期）UpdatedAt- 用于合并时的冲突解决
每个实例独立地
- 根据当前时间评估抑制状态（待定/活动/已过期）
- 垃圾回收超过保留期的过期抑制
- GC 仅在本地进行（无 gossip），因为所有实例都会收敛到相同的决策
单一管理界面
用户可以与集群中的任何 Alertmanager 实例进行交互
- 查看抑制 - 所有实例具有相同的抑制状态（最终一致）
- 创建/更新抑制 - 在任何实例上进行的更改会传播到所有节点
- 删除抑制 - 实现为“立即过期”+ gossip
这提供了统一的运维体验，无论您访问哪个实例。
运维注意事项
配置
要配置集群，每个 Alertmanager 实例需要
# alertmanager.yml
global:
# ... other config ...
# No cluster config in YAML - use CLI flags命令行标志
alertmanager \
--cluster.listen-address=0.0.0.0:9094 \
--cluster.peer=am-1.example.com:9094 \
--cluster.peer=am-2.example.com:9094 \
--cluster.peer=am-3.example.com:9094 \
--cluster.advertise-address=$(hostname):9094 \
--cluster.peer-timeout=15s \
--cluster.gossip-interval=200ms \
--cluster.pushpull-interval=60s关键标志
--cluster.listen-address- 集群通信的绑定地址（默认：0.0.0.0:9094）--cluster.peer- 节点地址列表（可重复）--cluster.advertise-address- 通知的节点地址（省略时自动检测）--cluster.peer-timeout- 去重每个节点位置的等待时间（默认：15s）--cluster.gossip-interval- gossip 频率（默认：200ms）--cluster.pushpull-interval- 完全状态同步间隔（默认：60s）--cluster.probe-interval- 节点健康检查间隔（默认：1s）--cluster.settle-timeout- 等待 gossip 稳定的最长时间（默认：context 超时）
Prometheus 配置
重要：配置 Prometheus 将告警发送到**所有** Alertmanager 实例，而不是通过负载均衡器。
# prometheus.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- am-1.example.com:9093
- am-2.example.com:9093
- am-3.example.com:9093这确保了
- 冗余 - 如果一个 Alertmanager 宕机，其他实例仍然可以接收告警
- 独立处理 - 每个实例独立评估路由、分组和去重
- 无单点故障 - 负载均衡器引入了单点故障
集群大小的考虑
由于 Alertmanager 使用 gossip 而没有法定人数或投票，**任何 N 个实例都能容忍 N-1 次故障** - 只要有一个实例存活，通知就会发送。
但是，集群大小涉及权衡
更多实例的好处
- 对同时发生的故障（硬件、网络、数据中心中断）具有更大的弹性
- 即使在维护窗口期间也能继续运行
更多实例的成本
- 在发生分区时，重复通知的数量会增加
- 更多的 gossip 流量
典型部署
- 2-3 个实例 - 单数据中心生产部署的常见配置
- 4-5 个实例 - 多数据中心或高度关键环境
注意：与基于共识的系统（etcd、Raft）不同，奇数与偶数集群大小没有区别——没有投票或法定人数。
监控集群健康
需要监控的关键指标
# Cluster size
alertmanager_cluster_members
# Peer health
alertmanager_cluster_peer_info
# Peer position (affects notification timing)
alertmanager_peer_position
# Failed peers
alertmanager_cluster_failed_peers
# State replication
alertmanager_nflog_gossip_messages_propagated_total
alertmanager_silences_gossip_messages_propagated_total
安全性
默认情况下，集群通信是未加密的。对于生产部署，尤其是在 WAN 上，请使用双向 TLS
alertmanager \
--cluster.tls-config=/etc/alertmanager/cluster-tls.yml有关详细信息，请参阅 保护集群流量。
持久化
每个 Alertmanager 实例会持久化
- 抑制 - 存储在快照文件中（默认：
data/silences） - 通知日志 - 存储在快照文件中（默认：
data/nflog）
重启后
- 实例从磁盘加载抑制和通知日志
- 加入集群并与节点进行 gossip 通信
- 合并从节点接收的状态（时间戳较新的获胜）
- 在 gossip 稳定后开始处理通知
注意：告警本身**不会**持久化——Prometheus 会定期重新发送触发的告警。
常见陷阱
-
Prometheus → Alertmanager 负载均衡
- ❌ 不要使用负载均衡器
- ✅ 在 Prometheus 中配置所有实例
-
未等待 gossip 稳定
- 可能导致启动时错过抑制或发送重复通知
--cluster.settle-timeout标志控制此行为
-
阻止集群端口的网络 ACL
- 确保端口 9094（或您的
--cluster.listen-address端口）在所有实例之间开放 - 默认使用 TCP 和 UDP（如果使用 TLS 传输，则仅使用 TCP）
- 确保端口 9094（或您的
-
不可路由的通告地址
- 如果未设置
--cluster.advertise-address，Alertmanager 会尝试自动检测 - 对于云/NAT 环境，请明确设置可路由的地址
- 如果未设置
-
不匹配的集群配置
- 所有实例应具有相同的
--cluster.peer-timeout和 gossip 设置 - 不匹配可能导致不必要的重复或遗漏通知
- 所有实例应具有相同的
工作原理：端到端示例
场景：3 实例集群，新的告警分组
- 告警到达所有 3 个实例（来自 Prometheus）
- 调度器创建聚合分组，等待
group_wait（例如 30 秒） - 等待 group_wait 后:
- 每个实例准备发送通知
- 通知阶段:
- 所有实例等待 gossip 稳定（如果刚启动）
- AM-1（位置 0）：等待 0 秒，检查通知日志（为空），发送通知，记录到 nflog
- AM-2（位置 1）：等待 15 秒，检查通知日志（看到 AM-1 的条目），**跳过**通知
- AM-3（位置 2）：等待 30 秒，检查通知日志（看到 AM-1 的条目），**跳过**通知
- 结果：发送了恰好一个通知（由 AM-1 发送）
场景：AM-1 失败
- 告警仅到达 AM-2 和 AM-3
- 调度器创建分组，等待
group_wait - 通知阶段:
- AM-1 不在集群中（探测失败）
- **AM-2** 现在是位置 0：等待 0 秒，发送通知
- **AM-3** 现在是位置 1：等待 15 秒，看到 AM-2 的条目，跳过
- 结果：通知仍发送（故障开放）
场景：通知期间的网络分区
- 告警到达所有实例
- **网络分区**将 AM-1 与 AM-2/AM-3 分开
- 在分区 A（AM-1）
- 位置 0，等待 0 秒，发送通知
- 在分区 B（AM-2, AM-3）
- AM-2 是位置 0，等待 0 秒，发送通知
- AM-3 是位置 1，等待 15 秒，进行去重
- 结果：发送了两个通知（每个分区一个）——故障开放行为
故障排除
检查集群状态
# View cluster members via API
curl http://am-1:9093/api/v2/status
# Check metrics
curl http://am-1:9093/metrics | grep cluster诊断脑裂
如果您怀疑脑裂
- 检查每个实例上的
alertmanager_cluster_members- 应与集群总大小匹配
- 检查
alertmanager_cluster_peer_info{state="alive"}- 应显示所有对等节点都处于活动状态
- 审查实例之间的网络连接
调试重复通知
重复通知可能由以下原因引起
- 网络分区（预期，容错开启）
- Gossip 未稳定 - 检查
--cluster.settle-timeout - 时钟偏差 - 确保所有实例都配置了 NTP
- 通知日志未复制 - 检查 gossip 指标
启用调试日志记录
alertmanager --log.level=debug查找
"等待 Gossip 稳定...""Gossip 已稳定；继续"- 通知管道中的去重决策