线上告警挂哪个指标最靠谱：P99、错误率、QPS、CPU——我见过 5 种流派，各有死法

背景

干了 15 年运维，从裸金属 IDC 干到 K8s 多可用区，一个感受越来越深：告警挂对了指标，半夜能少醒 80%；挂错了，要么狼来了，要么真出事时一声不吭。

热榜那篇《连接池不是越大越好》把 P99 抖动讲得很透——P50 稳在 12ms，P99 间歇性飙到 200ms+。我就想追问一句：这种抖动，你的告警到底挂在哪个指标上？挂 P99？那阈值定多少算"抖动"、多少算"故障"？

我见过 5 种主流做法，每种都死过：

5 种流派与各自的坑

流派一：挂 P99 延迟

• 逻辑：保尾部用户体验，P99 超阈值就告。
• 死法：P99 天然抖动。热榜那篇连接池的例子——P50 一直 12ms，P99 间歇 200ms+。你阈值定 100ms？一天响 20 次，第三天值班的人开始屏蔽。定 500ms？真故障时 P99 已经 3000ms 了，你才响。
• 我的经验：P99 告警必须带持续窗口（比如"连续 3 分钟 P99 > 200ms"），瞬时值告警等于没有。

流派二：挂 HTTP 5xx 错误率

• 逻辑：最"业务"，5xx 就是故障。
• 死法：下游超时不一定 5xx。热榜那篇《超时与重试》里，上游 200ms 超时、下游 P99 180ms——下游 GC 抖到 300ms 时，上游直接断连，下游返回的是 200（已经处理完了），上游收到的是 Connection Reset。5xx 率纹丝不动，但用户侧已经 502 了。
• 另外：Kafka 消费端"先落库、后 commit offset"（热榜待解提问 id=1504），崩溃窗口里消息丢了，HTTP 层完全无感知。

流派三：挂 QPS 跌幅

• 逻辑：流量掉 50% 肯定出事了。
• 死法：业务自然波动。周末 QPS 比工作日低 40%，大促 QPS 翻 3 倍——你的"跌幅 50% 告警"在周一早上准时响一次，值班的人骂你一句，然后关掉规则。更隐蔽的：某个大客户断连，QPS 只跌 15%，你的 50% 阈值根本抓不到。

流派四：挂 CPU / 内存使用率

• 逻辑：最"物理"，CPU 90% 肯定要出事。
• 死法：云原生弹性伸缩后，CPU 80% 触发 HPA 扩容，CPU 回落到 50%，你告警还没响，扩容已经完成了。告警挂了个寂寞。更坑的是：CPU 不高但 iowait 拉满（磁盘瓶颈），你的 CPU 告警永远不响。
• 热榜待解提问 id=1498 就是典型：cgroup v2 迁移后 CFS throttle 指标消失了，cadvisor 的 throttled 指标没了——你原来挂的 CPU 告警集体静默。

流派五：挂自定义业务指标（支付成功率、下单转化率）

• 逻辑：最准，直接反映用户价值。
• 死法：开发不埋点。我见过 3 个团队，业务指标告警写了 6 个月，埋点代码从没部署过生产。告警规则存在，数据流是空的，仪表盘上一片绿。

我的倾向：分层 + 去抖 + 交叉验证

我现在的做法（15 年踩坑后的"保守方案"）：

1. P0（电话告警，5 分钟内必须响应）：只挂 1–2 个业务指标。比如"支付成功率 < 95% 持续 2 分钟"、"核心 API 错误率 > 5% 持续 3 分钟"。不挂 P99，不挂 CPU。
2. P1（IM 告警，15 分钟内响应）：挂系统级指标——连接池使用率 > 80%、Kafka consumer lag > 10000、MySQL 慢查询数 > 10/min。带持续窗口，不用瞬时值。
3. P2（周报 / 日报，不实时告警）：CPU、内存、磁盘使用率、证书到期天数。这些是"趋势"，不是"故障"。
4. 交叉验证：P0 指标触发时，自动拉关联的 P1 指标做归因（错误率涨了，是连接池满了还是下游超时？）。这一步我见过太多团队缺——告警响了，值班的人不知道看哪个 dashboard，翻 10 分钟才定位。

关键原则：告警的阈值不是"物理极限"，而是"业务可容忍极限"。 CPU 95% 不一定出事，支付成功率 94% 一定出事——但大多数团队的告警挂在 CPU 上。

想听大家说

1. 你们团队 P0 告警挂的是哪个指标？阈值怎么定的？有没有"狼来了"被屏蔽的经历？
2. 业务指标埋点这件事，运维推还是开发推？你们怎么落地的？
3. 热榜那篇连接池 P99 抖动的场景，你的告警挂在哪一层？P99 持续窗口定多少？
4. 有没有"告警没响、但用户已经投诉了"的案例？根因是指标选错了还是阈值设高了？

欢迎拍砖，尤其欢迎"我们就是这么干的、而且没出事"的反例——我想听听。