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

2. Prometheus 告警体系回顾：Alertmanager 架构、告警分组、抑制与静默机制

在生产运维中，Prometheus 负责采集指标并触发告警，但真正决定告警“怎么发、发给谁、是否重复、是否屏蔽”的核心组件是 Alertmanager。本章从架构、分组、抑制、静默四个维度，系统梳理 Alertmanager 的工作原理与配置要点，为后续 Runbook 自动化联动打下基础。

2.1 Alertmanager 整体架构

Alertmanager 接收来自 Prometheus Server 的告警，经过去重、分组、抑制、静默处理后，通过路由树将告警发送到不同的接收器（Receiver）。其核心流程如下：

架构要点：Alertmanager 采用管道式处理模型，告警依次经过去重 → 分组 → 抑制 → 静默 → 路由 → 发送。路由树根据标签匹配决定告警进入哪个接收器，接收器支持 Email、PagerDuty、Slack、Webhook 等。

2.2 告警分组（Grouping）

告警分组是 Alertmanager 最核心的降噪手段。它将同一时间窗口内、具有相同标签集的告警合并为一条通知，避免“告警风暴”导致接收者被大量重复消息淹没。

2.2.1 分组配置参数

参数	说明	默认值	推荐值（生产）
`group_by`	按哪些标签分组，如 `['alertname', 'severity']`	`['alertname']`	`['alertname', 'severity', 'cluster']`
`group_wait`	等待同一组告警的最长时间，期间新告警会合并	`30s`	`30s ~ 1m`
`group_interval`	同一组告警发送间隔，避免频繁通知	`5m`	`5m ~ 10m`
`repeat_interval`	告警未恢复时重复发送的间隔	`4h`	`4h ~ 12h`

2.2.2 分组配置示例

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default-receiver'
  routes:
    - match:
        severity: 'critical'
      receiver: 'critical-receiver'
      group_wait: 10s
      repeat_interval: 1h

  分组效果：假设 1 分钟内触发了 20 条 CPUUsageHigh 告警（不同主机），Alertmanager 会将其合并为 1 条通知，内容包含所有受影响的主机列表，而非发送 20 条独立消息。

2.3 抑制（Inhibition）

抑制机制允许高优先级告警“屏蔽”低优先级告警。例如：当节点宕机（NodeDown）时，该节点上的所有服务告警（如 ProcessDown、DiskFull）都应被抑制，因为根源是节点不可达，服务告警是衍生噪声。

2.3.1 抑制规则配置

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

字段	说明
`source_match`	源告警（高优先级）的匹配条件
`target_match`	目标告警（被抑制）的匹配条件
`equal`	源和目标必须具有相同值的标签列表，确保抑制只作用于同一实例/集群

抑制陷阱：如果 equal 标签设置过少，可能导致跨实例误抑制。例如 equal: ['alertname'] 会使所有 CPUUsageHigh 告警被一个 NodeDown 抑制，即使它们不在同一节点。务必包含 instance 或 host 标签。

2.4 静默（Silence）

静默用于在指定时间窗口内，根据标签匹配主动屏蔽告警。常用于：

计划内维护：升级、重启、扩容期间屏蔽相关告警。
已知问题：已确认的故障但暂时无法修复，临时静默避免干扰。
测试环境：屏蔽非生产环境的告警。

2.4.1 静默配置方式

静默可通过 Alertmanager 的 Web UI 或 amtool 命令行工具创建：

# 使用 amtool 创建静默
amtool silence add \
  --alertmanager.url=http://alertmanager:9093 \
  --author="sre-team" \
  --comment="Scheduled maintenance for node upgrade" \
  --duration=2h \
  --matcher="severity=warning" \
  --matcher="instance=web-01"

2.4.2 静默匹配规则

匹配类型	语法	示例
精确匹配	`key=value`	`severity=critical`
正则匹配	`key=~regex`	`instance=~"web-.*"`
排除匹配	`key!=value`	`severity!=info`

静默 vs 抑制：静默是主动、计划性的屏蔽，由运维人员手动或 API 创建；抑制是自动、规则驱动的屏蔽，由 Alertmanager 根据告警优先级和标签关系自动触发。两者结合使用，可有效管理告警噪声。

2.5 分组、抑制、静默协同工作流

2.6 配置最佳实践

分组粒度：按 alertname + severity + cluster 分组，避免跨集群告警合并导致上下文丢失。
抑制层级：建立清晰的告警优先级体系（critical > warning > info），确保抑制规则覆盖常见故障场景（如节点宕机 → 服务告警）。
静默自动化：通过 Alertmanager API 将静默集成到变更管理平台，实现维护窗口自动静默。
重复间隔：生产环境 repeat_interval 建议 4h 以上，避免夜间频繁打扰。