4. Alertmanager 基础：架构、分组、抑制与静默机制

Alertmanager 是 Prometheus 生态中负责告警路由、去重、分组、抑制和静默的核心组件。它接收来自 Prometheus 或其他兼容源的告警，通过灵活的配置将告警发送到正确的接收端（如邮件、PagerDuty、Slack），并有效防止告警风暴。本章深入剖析 Alertmanager 的内部架构与三大核心机制。

4.1 Alertmanager 架构概览

Alertmanager 采用管道式架构，告警从接收到发送经历多个处理阶段。理解其内部组件有助于精准排障与调优。

4.2 分组机制 (Grouping)

分组是 Alertmanager 防止告警风暴的第一道防线。它将同一时间窗口内、具有相同标签集的告警合并为一条通知，显著减少接收端的噪音。

4.2.1 分组配置参数

4.2.2 分组工作流程

1. 告警到达： Alertmanager 接收来自 Prometheus 的告警。
2. 标签匹配： 根据 group_by 中定义的标签提取分组键（如 {alertname="HighCPU", severity="critical"}）。
3. 等待窗口： 启动 group_wait 计时器，等待同一分组键的其他告警。
4. 发送通知： 计时器到期后，将组内所有告警合并为一条通知发送。
5. 后续更新： 在 group_interval 内，组内新告警不会触发新通知；超过 group_interval 后，若有新告警或状态变化，再次发送。

4.3 抑制机制 (Inhibition)

抑制用于消除由同一根本原因引发的冗余告警。例如，当节点宕机时，该节点上的所有服务告警都应被抑制，直到节点恢复。

4.3.1 抑制规则配置

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

4.3.2 抑制示例场景

• 基础设施故障： 主机宕机（源）抑制该主机上的所有进程/服务告警（目标）。
• 级联故障： 数据库不可用（源）抑制依赖该数据库的应用层告警（目标）。
• 维护窗口： 通过临时创建高优先级告警作为源，抑制同一资源上的低优先级告警。

4.4 静默机制 (Silence)

静默允许管理员在特定时间段内，根据标签匹配规则有选择地屏蔽告警通知。常用于计划内维护、已知问题临时容忍等场景。

4.4.1 静默的生命周期

1. 创建： 通过 Alertmanager API 或 Web UI 创建静默规则，指定匹配标签、持续时间和创建者。
2. 生效： 静默创建后立即生效，匹配的告警将不会触发通知，但告警状态仍会在 Alertmanager 中保留。
3. 过期： 到达设定的结束时间后，静默自动过期，告警恢复正常通知。
4. 手动过期： 管理员可随时手动过期静默，提前恢复通知。

4.4.2 静默配置示例

# 通过 API 创建静默
POST /api/v2/silences
{
  "matchers": [
    {
      "name": "instance",
      "value": "web-server-01",
      "isRegex": false
    },
    {
      "name": "severity",
      "value": "warning",
      "isRegex": false
    }
  ],
  "startsAt": "2025-04-01T00:00:00Z",
  "endsAt": "2025-04-02T00:00:00Z",
  "createdBy": "admin",
  "comment": "计划内维护：web-server-01 升级"
}

4.4.3 静默与抑制的区别

4.5 三大机制协同工作

在实际生产环境中，分组、抑制、静默按顺序协同处理告警流。下图展示了告警从进入 Alertmanager 到最终发送的完整决策路径。