📚 课程目录第2章 Prometheus告警体系回顾

2. Prometheus 告警体系回顾：Alertmanager 架构、告警分组与抑制、告警路由

在构建自愈剧本之前，必须深入理解 Prometheus 告警体系的核心枢纽——Alertmanager。它负责接收 Prometheus Server 推送的告警，并执行去重、分组、抑制、静默与路由，最终将通知发送到正确的接收端。本章将拆解 Alertmanager 的内部架构、分组与抑制机制、以及路由规则，为后续的 Runbook 模板化奠定基础。

2.1 Alertmanager 整体架构

Alertmanager 采用管道-过滤器架构，告警从入站到出站依次经过多个处理阶段。每个阶段都可以通过配置文件进行精细控制。

2.2 告警分组（Grouping）

分组是 Alertmanager 减少告警风暴的核心手段。它将同一时间窗口内、具有相同标签集的告警合并为一条通知，避免接收端被大量重复告警淹没。

2.2.1 分组配置参数

参数	说明	典型值
`group_by`	指定用于分组的标签列表，如 `['alertname', 'severity']`	`['alertname', 'cluster']`
`group_wait`	首次告警后等待同一组内其他告警的时间，用于收集	`30s`
`group_interval`	同一组告警已发送后，再次发送新告警的最小间隔	`5m`
`repeat_interval`	告警未解决时，重复发送通知的最小间隔	`4h`

最佳实践： 将 group_by 设置为 ['alertname', 'severity'] 可以确保同一严重级别的同类告警合并为一条通知，大幅降低告警噪音。

2.2.2 分组工作流程

告警到达： Alertmanager 接收来自 Prometheus 的告警。
标签提取： 根据 group_by 配置提取告警的标签值，生成分组键（Group Key）。
等待窗口： 在 group_wait 时间内，将相同分组键的告警收集到同一个缓冲区。
合并发送： 等待窗口结束后，将缓冲区内的所有告警合并为一条通知发送。
后续更新： 在 group_interval 内，新到达的同组告警会追加到已发送的通知中，不触发新通知。

2.3 告警抑制（Inhibition）

抑制用于在已知的根因告警已经触发时，自动屏蔽由其引发的衍生告警。例如，当节点宕机时，该节点上的所有服务不可用告警都应被抑制，直到节点恢复。

2.3.1 抑制规则配置示例

inhibit_rules:
  - source_matchers:
      - severity = critical
    target_matchers:
      - severity =~ warning|info
    equal:
      - instance

  规则解析： 当存在 severity=critical 的告警时，所有 severity 为 warning 或 info 且 instance 标签相同的告警将被抑制。这确保了只有最严重的告警被发送，避免告警风暴。

2.3.2 抑制与分组的交互

抑制发生在分组之后、路由之前。这意味着分组引擎已经将告警合并，抑制引擎再根据规则决定哪些分组后的通知需要被丢弃。这种顺序保证了抑制逻辑不会干扰分组聚合，同时减少了路由引擎的处理负担。

2.4 告警路由（Routing）

路由引擎根据告警的标签匹配结果，将通知分发到不同的接收端（Receiver）。路由树采用树形结构，支持嵌套路由，实现精细化的告警分发策略。

2.4.1 路由树结构

2.4.2 路由配置关键字段

字段	说明	示例
`receiver`	当前路由匹配后发送到的接收端名称	`team-critical`
`match`	精确匹配标签键值对	`severity: critical`
`match_re`	正则匹配标签值	`severity: ~"critical\|warning"`
`continue`	匹配后是否继续评估子路由（默认 false）	`true`
`routes`	子路由列表，支持嵌套	`[...]`

注意： 路由匹配是深度优先的。一旦某个路由匹配成功且 continue 为 false，则停止向下搜索。合理设置 continue 可以实现告警的多路分发。

2.5 本章小结

Alertmanager 的架构设计围绕减少噪音、精准路由、根因聚焦三个目标展开。分组机制通过标签聚合降低通知数量；抑制机制通过依赖关系屏蔽衍生告警；路由机制通过树形匹配实现灵活分发。这三者共同构成了 Prometheus 告警体系的稳定基石，也是后续自愈剧本中判断告警上下文、触发自动化恢复动作的前提条件。