跳到主要内容

告警策略

告警设计原则​

原则说明
可操作性每条告警必须有对应的处理动作
分级明确不同级别走不同渠道，避免告警疲劳
减少噪音聚合、抑制、去重，避免告警风暴
持续时间设置 for 避免短暂抖动触发告警
有意义的描述告警内容包含：什么问题、影响范围、处理建议

告警分级​

级别标准响应时间通知渠道
P0 Critical业务完全不可用5 分钟电话 + 短信 + IM
P1 Major核心功能受损15 分钟短信 + IM
P2 Warning非核心功能异常/资源预警30 分钟IM 群
P3 Info需关注但不紧急工作时间邮件 / IM

分级示例​

告警级别理由
服务全部实例不可达P0业务完全中断
错误率 > 10%P1大量用户受影响
CPU > 85% 持续 10mP2资源预警，有缓冲时间
磁盘 4h 后预计满P2需要提前处理
SSL 证书 30 天后过期P3提前提醒

Alertmanager 配置​

alertmanager.yml
global:
  resolve_timeout: 5m

# 路由规则
route:
  receiver: default-im              # 默认接收器
  group_by: [alertname, namespace]  # 按告警名和命名空间分组
  group_wait: 30s                   # 分组等待时间
  group_interval: 5m                # 组内间隔
  repeat_interval: 4h               # 重复告警间隔

  routes:
    # P0: 电话通知
    - match:
        severity: critical
      receiver: pager
      repeat_interval: 15m
      continue: true                 # 继续匹配后续规则

    # P0 + P1: IM 通知
    - match_re:
        severity: critical|major
      receiver: im-oncall
      repeat_interval: 30m

    # P3: 邮件
    - match:
        severity: info
      receiver: email

# 抑制规则：critical 告警触发时，抑制同实例的 warning
inhibit_rules:
  - source_match:
      severity: critical
    target_match:
      severity: warning
    equal: [alertname, instance]

# 接收器
receivers:
  - name: default-im
    webhook_configs:
      - url: http://alert-bot:8080/webhook/im
  - name: pager
    webhook_configs:
      - url: http://alert-bot:8080/webhook/pager
  - name: im-oncall
    webhook_configs:
      - url: http://alert-bot:8080/webhook/oncall
  - name: email
    email_configs:
      - to: 'ops-team@example.com'

告警收敛技术​

分组（Grouping）​

同一时间段、同一类告警合并为一条通知：

group_by: [alertname, cluster]
group_wait: 30s       # 等待 30s 收集同组告警
group_interval: 5m    # 新告警加入组的间隔

抑制（Inhibition）​

高级别告警触发时，自动抑制低级别告警：

# 当 HostDown 触发时，自动抑制该主机的所有 Warning 告警
inhibit_rules:
  - source_match:
      alertname: HostDown
    target_match:
      severity: warning
    equal: [instance]

静默（Silence）​

临时屏蔽告警（维护窗口期）：

# 创建 Silence（通过 Alertmanager API 或 UI）
# 屏蔽某主机 2 小时的所有告警
amtool silence add instance=web-01:9100 --duration=2h --comment="计划维护"

SLO 告警​

基于 SLO（Service Level Objective）的告警，关注对用户的实际影响。

# 可用性 SLO：99.9%（每月允许 43 分钟不可用）
# 如果最近 1 小时的错误预算消耗超过月度预算的 2%，则告警

# 步骤 1：计算错误率
- record: slo:error_rate:5m
  expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# 步骤 2：基于燃烧率的告警
- alert: SLOBudgetBurning
  expr: slo:error_rate:5m > 14.4 * (1 - 0.999)   # 14.4x 燃烧率 = 1 小时消耗 2% 月度预算
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "SLO 错误预算快速消耗（燃烧率 14.4x）"
SLO 告警优于阈值告警

传统告警：错误率 > 1% → 告警（可能一次短暂尖刺就触发） SLO 告警：错误率 × 持续时间 > 预算消耗速率 → 告警（关注累计影响）

常见面试问题​

Q1: 如何减少告警噪音？​

答案：

  1. 设置 for 持续时间：避免短暂抖动触发告警
  2. 分组聚合：相同类型告警合并通知
  3. 抑制规则：高级别告警触发时抑制低级别
  4. 静默：维护期临时屏蔽
  5. 阈值调优：基于历史数据调整阈值
  6. SLO 告警：关注对用户的实际影响

Q2: 告警分级怎么设计？​

答案：

按业务影响分 4 级：

  • P0 Critical：用户完全不可用 → 电话通知 → 5 分钟响应
  • P1 Major：核心功能受损 → IM + 短信 → 15 分钟响应
  • P2 Warning：资源预警 → IM → 30 分钟响应
  • P3 Info：非紧急 → 邮件 → 工作时间处理

关键是每个级别有明确的响应 SLA 和升级机制。

相关链接​