17.11.3 告警分级、抑制与值班流程

告警分级应以业务影响与可恢复性为核心，形成统一标准并在全域执行。建议按 P1/P2/P3（或紧急/高/中/低）分级：P1 影响核心链路、用户不可用或数据丢失风险；P2 影响重要功能或性能显著下降；P3 为容量预警、单点异常或不影响用户的告警。每条告警必须定义级别、影响范围、触发条件、责任团队与期望响应时间（TTR）/恢复时间（RTO），并在 Alertmanager 中通过标签固化，例如 severity、service、team、env。

原理草图（告警分级、抑制与通知链路）：

告警规则与分级示例（Prometheus 规则文件）：

# /etc/prometheus/rules/alert.rules.yml
groups:
- name: base-alerts
  rules:
  - alert: ServiceDown
    expr: up{job="api"} == 0
    for: 2m
    labels:
      severity: P1
      service: api
      team: platform
      env: prod
    annotations:
      summary: "API 服务不可用"
      description: "api 实例 {{ $labels.instance }} 连续 2 分钟不可用"
  - alert: HighErrorRate
    expr: (sum(rate(http_requests_total{job="api",code=~"5.."}[5m])) /
          sum(rate(http_requests_total{job="api"}[5m]))) > 0.02
    for: 5m
    labels:
      severity: P2
      service: api
      team: platform
      env: prod
    annotations:
      summary: "API 5xx 错误率过高"
      description: "5xx 错误率持续 5 分钟 > 2%"

Alertmanager 分级路由与抑制示例：

# /etc/alertmanager/alertmanager.yml
route:
  group_by: ['alertname','service','env']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  receiver: "default-im"
  routes:
  - match:
      severity: P1
    receiver: "oncall-p1"
  - match:
      severity: P2
    receiver: "oncall-p2"
  - match:
      severity: P3
    receiver: "mail-only"

inhibit_rules:
- source_match:
    alertname: ServiceDown
    severity: P1
  target_match:
    alertname: HighErrorRate
  equal: ['service','env']

receivers:
- name: "oncall-p1"
  webhook_configs:
  - url: "https://im.example.com/notify?channel=oncall-p1"
- name: "oncall-p2"
  webhook_configs:
  - url: "https://im.example.com/notify?channel=oncall-p2"
- name: "mail-only"
  email_configs:
  - to: "ops@example.com"

短时抖动抑制（for）与多维触发示例：

# /etc/prometheus/rules/alert.rules.yml
- alert: LatencyAndTrafficSpike
  expr: (histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.6)
    and (sum(rate(http_requests_total[5m])) > 200)
  for: 5m
  labels:
    severity: P2
    service: api
  annotations:
    summary: "延迟与流量同时异常"
    description: "P95 延迟>0.6s 且 QPS>200 持续 5 分钟"

值班流程需明确“触发—通知—响应—升级—复盘”的闭环。通知渠道建议分级：P1 触发电话/短信+IM，P2 IM+邮件，P3 仅邮件或工单。响应时限建议：P1 5–10 分钟内响应、30–60 分钟内恢复或提供替代方案；P2 30 分钟内响应、2–4 小时内恢复；P3 1 个工作日内处理。值班手册需包含服务拓扑、告警解释、定位路径、常用命令与应急操作。升级路径需明确：一线值班→二线专家→研发负责人→管理层，并在工单或事件管理系统中记录时间线与处理人。

值班流程时序图：

sequenceDiagram
  participant AM as Alertmanager
  participant OC as OnCall
  participant L2 as 二线专家
  participant RD as 研发负责人
  AM->>OC: P1/P2/P3 通知
  OC->>OC: 确认&响应
  OC->>L2: 升级(超时/无解)
  L2->>RD: 重大影响升级
  RD->>OC: 方案与回退
  OC->>AM: 标记恢复/静默

安装与基础操作（Alertmanager 工具 amtool）：

# 安装 amtool（以 Linux 包为例，路径可按实际版本调整）
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar -xzf alertmanager-0.27.0.linux-amd64.tar.gz
sudo cp alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/

# 查看当前告警
amtool --alertmanager.url=http://127.0.0.1:9093 alert

# 创建静默（维护窗口抑制）
amtool --alertmanager.url=http://127.0.0.1:9093 silence add \
  alertname=ServiceDown service=api env=prod \
  --duration=2h --comment="发布维护窗口"

# 查看与删除静默
amtool --alertmanager.url=http://127.0.0.1:9093 silence
amtool --alertmanager.url=http://127.0.0.1:9093 silence expire <silence_id>

常用排错与验证命令（含解释）：

# 校验 Alertmanager 配置语法
amtool check-config /etc/alertmanager/alertmanager.yml

# 校验 Prometheus 规则文件
promtool check rules /etc/prometheus/rules/alert.rules.yml

# 查看告警规则是否加载
curl -s http://127.0.0.1:9090/api/v1/rules | jq '.data.groups[].rules[].name'

# 手工触发测试告警（Pushgateway 模拟）
echo "test_metric 1" | curl --data-binary @- http://127.0.0.1:9091/metrics/job/test

故障排查要点：
- 未触发告警：检查规则表达式是否有数据、for 时间是否过长、labels 是否一致。
- 告警未通知：检查 Alertmanager route 匹配、receiver 可达性、Webhook 返回码。
- 抑制无效：检查 inhibit_rules 的 equal 标签是否一致。

运维规范与演练要求：
- 新增告警必须通过评审，包含触发条件、业务影响说明、抑制关系与测试用例。
- 告警阈值与 SLO/基线绑定，月度复盘调整。
- 统计指标：误报率、重复率、平均响应时间、平均恢复时间、夜间唤醒次数。

练习（含预期效果）：
1. 创建一条 P1 告警并路由到 oncall-p1，验证能收到 IM 通知。
2. 为 ServiceDown 添加 inhibit_rules，验证 HighErrorRate 在 ServiceDown 期间被抑制。
3. 用 amtool 创建 1 小时静默，确认告警不再触发通知。
4. 使用 promtool 检查规则语法错误并修复。