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

3. Prometheus 告警体系回顾：告警规则、路由、抑制与静默

在规划升级窗口容量之前，必须统一团队对 Prometheus 告警体系的理解。告警从产生到通知，经历 规则评估 → Alertmanager 路由 → 抑制/静默 → 通知 四个阶段。任何一阶段的配置偏差都会导致告警风暴或漏报，直接影响升级窗口的容量评估准确性。

3.1 告警规则：触发条件的定义

告警规则写在 Prometheus Server 的配置文件中，通过 groups 组织。每条规则包含：告警名称、表达式、持续时间、标签和注解。

groups:
  - name: example_alerts
    rules:
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} CPU usage > 80%"
          description: "CPU usage has been above 80% for more than 5 minutes."

字段	作用	常见陷阱
`expr`	PromQL 表达式，返回非空向量时触发	聚合维度缺失导致误报；`rate`/`increase` 窗口过短
`for`	持续时间，防止瞬时抖动触发告警	设置过短（如 10s）无法过滤毛刺；过长（如 30m）延迟发现
`labels`	附加标签，用于 Alertmanager 路由匹配	标签值不统一（如 `critical` vs `Critical`）导致路由失效
`annotations`	告警描述信息，发送给接收端	模板变量引用错误导致通知内容为空

容量规划视角： 升级窗口期间，建议临时调高 for 持续时间（如从 5m 改为 15m），避免因重启、滚动升级产生的瞬时指标抖动触发不必要的告警。

3.2 Alertmanager 路由：告警的分发策略

Alertmanager 通过 route 树状结构匹配告警标签，决定告警发送到哪个接收器（Receiver）。路由匹配遵循 最长前缀匹配 原则：子路由匹配优先级高于父路由。

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      repeat_interval: 1h
    - match_re:
        service: ^(api|web)$
      receiver: 'slack-team'

路由参数	含义	对升级窗口的影响
`group_wait`	同类告警首次发送前的等待时间	过短（如 10s）导致碎片通知；过长（如 5m）延迟响应
`group_interval`	同类告警合并发送的间隔	升级期间建议缩短至 2-3m，避免告警积压
`repeat_interval`	已发送告警的重复通知间隔	升级窗口可临时调长至 8h，减少重复打扰

常见路由失效场景： 子路由的 match 标签与告警规则中的 labels 拼写不一致（如 severity: critical vs severity: Critical），导致告警落入默认接收器，关键通知被淹没。

3.3 抑制机制：避免级联告警风暴

抑制（Inhibition）用于在已知故障发生时，屏蔽由其引发的衍生告警。典型场景：节点宕机后，该节点上的所有进程、服务、磁盘告警都应被抑制。

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

字段	含义	升级窗口使用建议
`source_match`	源告警（主故障）的匹配条件	升级期间可增加 `severity: critical` 作为源
`target_match`	被抑制告警（衍生告警）的匹配条件	建议抑制所有 `warning` 级别衍生告警
`equal`	标签列表，源和目标在这些标签上值相等时才抑制	必须包含 `instance` 或 `cluster`，避免跨节点误抑制

  升级窗口最佳实践： 在升级窗口开始前，动态注入一条抑制规则：source_match: {severity: "critical"} target_match: {severity: "warning"} equal: ['instance']。这能有效防止因节点重启导致的数十条 warning 告警同时涌出。

3.4 静默机制：计划内维护的告警屏蔽

静默（Silence）用于在计划维护期间，根据标签匹配屏蔽特定告警。静默可以通过 Alertmanager Web UI 或 amtool 命令行创建，支持设置过期时间。

# 使用 amtool 创建静默
amtool silence add \
  --duration=2h \
  --comment="Upgrade window: api-server rolling update" \
  --matcher="instance=10.0.1.5:9090" \
  --matcher="alertname=~High.*"

静默属性	说明	升级窗口注意事项
`matcher`	标签匹配器，支持精确匹配和正则	匹配器过宽会屏蔽真实故障；过窄则漏屏蔽
`duration`	静默持续时间	建议设置为升级窗口时长 + 30 分钟缓冲
`comment`	静默原因说明	必须包含升级窗口 ID 和负责人，便于事后审计

静默与抑制的区别： 抑制是自动的、基于告警关系的屏蔽；静默是手动的、基于时间窗口的屏蔽。升级窗口应优先使用静默，因为抑制规则可能因源告警未触发而失效。

3.5 告警体系配置清单（升级窗口检查项）

在每次升级窗口前，使用以下清单验证告警体系配置，确保容量规划基线不受告警噪声干扰：

告警规则：确认 for 持续时间已临时调高至 15m 以上；检查 PromQL 表达式是否包含 instance 标签，避免聚合丢失维度。
路由配置：验证 group_interval 是否缩短至 3m 以内；确认 repeat_interval 已调长至 8h 以上。
抑制规则：注入升级专用抑制规则，源为 severity=critical，目标为 severity=warning，equal 包含 instance。
静默条目：为所有升级目标实例创建静默，持续时间 = 窗口时长 + 30m，注释包含升级工单号。
通知验证：发送测试告警，确认路由、抑制、静默均按预期生效。

自动化建议： 将上述检查项封装为 pre-upgrade-check.sh 脚本，通过 Prometheus API 和 amtool 自动验证配置，输出通过/失败报告，作为升级窗口容量规划基线的准入条件。