告警体系

告警的目的

"在影响用户之前，叫到一个能解决问题的人。"

不是为了"全部都监控起来"——监控数据可以全留，告警是稀缺资源：滥用就疲劳，疲劳就漏报。

分级：建议从两级起步

很多公司用 P0–P3 四级，但实操中两级最有效：

级别	含义	通知方式
Page（叫人）	必须现在处理（生产宕、SLO 即将燃尽）	电话 / 短信 / PagerDuty / 飞书加急
Ticket（开单）	重要但可以等到工作时间	Slack / 邮件 / Issue

多级体系（P0–P3）容易让人钻空子——"P3 不用立刻看" 慢慢就没人看了。

Alertmanager（Prometheus 生态）

Alertmanager 不只是 Prometheus 配套——很多其他系统也走它（Thanos / VictoriaMetrics / Cortex）。

核心能力：

路由（routing）：按 label 转给不同接收人
分组（grouping）：相同 incident 的 N 条告警合成一条
抑制（inhibition）：A 触发时屏蔽 B（如"集群挂"屏蔽"应用挂"）
沉默（silencing）：手动暂停某段时间的告警（值班里要发版了）

一份基础配置

alertmanager.yml:

route:
  receiver: ticket-default
  group_by: [alertname, cluster, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: page-oncall
      group_wait: 10s
      repeat_interval: 30m

receivers:
  - name: page-oncall
    pagerduty_configs:
      - service_key: ${PAGERDUTY_KEY}

  - name: ticket-default
    slack_configs:
      - api_url: ${SLACK_WEBHOOK}
        channel: "#alerts"

inhibit_rules:
  - source_matchers: [severity="page", alertname="ClusterDown"]
    target_matchers: [severity="page"]
    equal: [cluster]

Symptom-based vs Cause-based

Google SRE Book 强烈推荐症状告警而不是原因告警：

❌ 原因：CPU 使用率 90% → 告警
✓ 症状：用户感知到的错误率 > 1% → 告警

理由：用户不在乎 CPU——CPU 90% 但响应正常 = 没事；CPU 30% 但 5xx 一片 = 大事。

一种例外：基础容量类指标（磁盘满、证书过期）——这类未来必然成事故，提前告警。

减少疲劳的几条原则

每条告警必须有 Runbook 链接——半夜被叫醒的人能立刻知道"怎么办"
告警阈值经常审：每月看一遍触发率最高的 alerts
fire 完不要 auto-resolve 就当过去：每条 page 都要复盘是否合理
不要把 INFO 当告警发："系统启动了""备份完成"应该进日志，不进告警

通知渠道

渠道	适合
PagerDuty / Opsgenie	Page 级，有轮班 / 升级路径
Slack / 飞书 / 钉钉	Ticket 级，团队可见
邮件	摘要 / 报告
短信 / 电话	兜底（PagerDuty 等都集成）
Issue（Jira / GitHub）	长期跟踪类

国内场景：飞书 / 钉钉 / 企业微信都有 webhook，可以接 Alertmanager。

反模式

告警接到群里没人 ack：群消息会被滚走，重要告警走 PagerDuty 这种有 ack/escalation 的工具
每条告警都炸给全团队：路由到具体责任人 / 服务 owner
数百条告警同时触发：分组没配好，配 group_by
告警依赖单点 Alertmanager：HA 部署 + 多副本，否则告警系统挂了你也不知道