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

2. Prometheus 告警体系回顾：Alertmanager 架构、告警生命周期与分组抑制基础

在深入告警降噪与阈值校准之前，必须重新梳理 Prometheus 告警体系的完整链路。告警并非由 Prometheus Server 直接发送给接收端，而是通过 Alertmanager 这一核心组件完成路由、分组、抑制与通知。理解 Alertmanager 的内部架构与告警状态机，是后续所有降噪策略的基石。

2.1 Alertmanager 整体架构

Alertmanager 是一个独立的二进制组件，负责接收 Prometheus Server 推送的告警，经过一系列内部处理后，最终将通知发送到邮件、PagerDuty、Slack、Webhook 等接收端。其核心工作流如下图所示：

  架构要点：Alertmanager 采用管道式处理模型，告警依次经过 接收 → 分组 → 抑制 → 静默 → 路由 → 通知。每个阶段都可以通过配置文件精细控制，这也是实现告警降噪的核心手段。

2.2 告警生命周期：Pending → Firing → Resolved

Prometheus 中的每条告警都经历一个严格的状态机。理解这三个状态，是正确配置告警规则与理解 Alertmanager 行为的前提。

状态	触发条件	Alertmanager 行为	典型场景
Pending	PromQL 表达式首次为 true，但未超过 `for` 持续时间	不发送通知；仅记录告警实例	CPU 突刺持续 30 秒，但 `for: 5m` 尚未满足
Firing	PromQL 表达式持续为 true，且超过 `for` 持续时间	进入 Alertmanager 处理管道，可能触发通知	CPU > 90% 持续超过 5 分钟
Resolved	PromQL 表达式从 true 恢复为 false	发送恢复通知（如果配置了 `send_resolved: true`）	CPU 回落到 90% 以下

最佳实践：合理设置 for 参数是告警降噪的第一道防线。对于瞬态抖动，设置 3-5 分钟的 for 可以避免大量无意义的 Pending 告警升级为 Firing。对于严重故障（如节点宕机），for 可以设为 0 或极短时间。

2.3 分组（Grouping）机制

分组是 Alertmanager 最强大的降噪手段之一。它将同一时间窗口内、具有相同标签集的多个告警合并为一条通知，避免“告警风暴”导致接收端被淹没。

分组的关键配置参数如下：

配置项	作用	推荐值
`group_by`	指定用于分组的标签列表（如 `['alertname', 'severity']`）	至少包含 `alertname`
`group_wait`	首次通知前等待更多同组告警的时间	30s ~ 1m
`group_interval`	同组告警已发送通知后，再次发送新通知的最小间隔	5m
`repeat_interval`	同组告警持续 Firing 时，重复发送通知的间隔	4h（生产环境建议 1-4h）

# 典型分组配置示例
route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'ops-team'

避坑提示：不要将 group_interval 设置过短（如 1 分钟），否则分组机制形同虚设。也不要将 repeat_interval 设置过长（如 24 小时），可能导致值班人员错过持续告警的更新。生产环境推荐 repeat_interval: 4h。

2.4 抑制（Inhibition）机制

抑制允许定义“当某类告警触发时，自动屏蔽另一类告警”。典型的场景是：当节点宕机（NodeDown）时，该节点上的所有服务不可用告警（ServiceDown）都应被抑制，因为根因是节点故障，服务告警只是衍生噪音。

抑制规则通过 inhibit_rules 配置，核心字段如下：

字段	说明	示例
`source_match`	匹配源告警（高优先级）的标签条件	`severity: critical`
`target_match`	匹配目标告警（被抑制）的标签条件	`severity: warning`
`equal`	源和目标必须具有相同值的标签列表	`['instance']`

# 典型抑制规则：当 critical 级别告警触发时，抑制同一 instance 的 warning 告警
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance']

  降噪效果：在大型集群中，一个节点宕机可能触发 50+ 条告警。通过抑制规则，只有 NodeDown 这条 critical 告警会发出通知，其余 49 条 warning 告警被自动静默，告警量直接减少 98%。

2.5 静默（Silences）机制

静默是 Alertmanager 提供的另一种告警屏蔽手段，与抑制不同，静默是 主动、临时 的屏蔽操作，通常由运维人员通过 Alertmanager UI 或 API 手动创建。静默基于标签匹配，可以设置过期时间。

使用场景：计划内维护、已知问题未修复前的临时屏蔽、变更窗口期。
匹配方式：支持精确匹配和正则匹配（matchers 字段）。
生命周期：静默创建后立即生效，到期后自动过期，也可手动过期。

# 通过 API 创建静默示例（简化）
POST /api/v2/silences
{
  "matchers": [
    { "name": "alertname", "value": "HighCpuUsage", "isRegex": false },
    { "name": "instance", "value": "web-.*", "isRegex": true }
  ],
  "startsAt": "2025-06-01T00:00:00Z",
  "endsAt": "2025-06-01T06:00:00Z",
  "createdBy": "sre-team",
  "comment": "计划内维护窗口"
}

与抑制的区别：抑制是 自动化、规则驱动 的，由告警之间的依赖关系触发；静默是 人工、临时 的，用于应对已知事件。两者结合使用，可以覆盖绝大多数告警噪音场景。

2.6 本章小结

Alertmanager 的架构设计围绕“降噪”这一核心目标展开：

分组解决“同类告警重复发送”问题；
抑制解决“衍生告警淹没根因”问题；
静默解决“已知事件干扰”问题；
告警生命周期 中的 for 参数，是降噪的第一道防线。