Alertmanager 架构与告警流程

Alertmanager 接收上游告警后，由 Dispatcher 按路由树和分组参数处理，再调用 Receiver 发送通知。API/UI 用于查看告警、管理静默和检查状态；集群成员通过 gossip 共享告警与静默状态。

1. 整体架构

Notification Pipeline 的每一段都可能失败：上游无法发送、路由不匹配、静默/抑制生效、接收器认证失败、网络超时或值班系统不可用。因此需要端到端测试而不只是检查进程存活。

2. 告警处理流程

1. Prometheus Rule 将告警发送至一个或多个 Alertmanager。
2. Alertmanager 根据告警标签匹配根路由和子路由。
3. 命中的告警按 group_by 聚合，并遵循等待与重复间隔。
4. 检查 Silence 和 Inhibition；被抑制的告警仍可在 UI 中查看。
5. Receiver 渲染模板并发送 firing 或 resolved 通知。

3. HA 架构

单节点适合实验。生产至少两个副本，使用同一配置和持久化策略，并通过 gossip 同步告警、静默和通知状态。Prometheus 可向多个副本发送，Alertmanager 负责去重。

集群降低单副本故障风险，但无法替代接收器健康检查。邮件网关、IM Webhook、电话平台和 DNS 仍是独立依赖。

4. 企业告警架构

层级	责任
监控层	Exporter、Prometheus、应用指标和规则评估
告警层	标签契约、Alertmanager 路由、静默、抑制与去重
通知层	IM、邮件、电话、Webhook、OnCall 和工单系统

各层应有负责人、变更流程和独立健康检查。核心用户影响只保留一个生产通知责任方，避免多个系统重复呼叫同一值班人员。