告警该「宁缺毋滥」还是「宁滥毋缺」：指标收敛到能行动的 20 个，还是全量采集等出事再翻？你的团队信噪比怎么扛？

【背景】 做指标体系第 5 年，我发现一个绕不开的矛盾：我们采的指标越来越多（一个核心服务 Prometheus 里 4000+ series，光 cardinality 就让我头疼），但真正在值班时「被看到、且能立刻采取行动」的告警，其实就那么十几个。

于是团队里逐渐分裂成两派，而且为此吵过好几轮：

• 收敛派：告警只保留「看到就能直接动手」的核心 20 个（错误率、P99、饱和度、依赖健康），其余只上 dashboard 不告警。理由：告警疲劳是真实的——一条没人看的 P2 弹窗，最终会把 P0 也一起淹掉。
• 全量派：能采的都采、该告的都告，靠值班老手的经验去下钻。理由：收敛一定会漏，漏掉的那个往往是最贵的；「我没报」的代价远大于「我多报了」。

两派都有道理，也都有翻车案例。我见过收敛派把「慢查询率」从告警里拿掉，结果一次索引失效拖了 40 分钟才被 P99 兜住；也见过全量派一天 60+ 条告警，值班同学直接静音，真出事时靠钉钉连轰才拉回来。

【常见分歧 / 几种做法】 1）收敛派：告警 = 可行动信号的白名单，宁可少不可滥； 2）全量派：全量采集 + 全量告警，把判断成本留给值班人； 3）分层派：把「行动层 / 容量趋势层 / 诊断层」拆开，不同层用不同通道。

【我的倾向与理由】 我倾向「分层」，但核心原则一句话：告警要收敛、数据要全量留痕。具体拆三层——

1. 行动层（真正弹窗告警）：只放「看到就能立刻执行一个明确动作」的指标，且必须绑定动作（谁、做什么、多久内）。这一层我强制用 SLO + burn rate 而不是裸阈值——「P99 < 500ms」这种绝对阈值我基本不信，更信「过去 1 小时 error budget 烧掉了 14%」这种相对信号，因为它自带「还剩多少余量、该多急」的语义，天然是分级依据。
2. 容量/趋势层（进周报，不弹窗）：cardinality 增长、连接池水位、磁盘增速、内存 RSS 趋势。这类不看会漏，但看了不紧急，放周报和 dashboard。
3. 诊断层（全量留痕，事后下钻）：所有细粒度指标都采，只是不主动告警，留给事后复盘和 on-call 下钻。

关键取舍在于：把「全量」的成本（存储、cardinality、值班心智负担）和「收敛」的风险（漏报）显式拆开——用「行动层收敛 + 诊断层全量」同时吃两边的红利。代价是 dashboard 和告警规则要维护两套，且分层标准会随业务漂移，得定期重审（我们按季度过一次）。

但我不确定这个分层在「小团队、人少、没有专职 SRE」的场景下是不是过度设计——一个人值班时，20 个行动层告警可能都嫌多。

【想听大家在什么场景下怎么选】

1. 你们团队的告警到底收敛到多少个？有没有「看到就能动手」的硬标准？
2. 裸阈值 vs SLO/burn rate，线上实际用哪个多？（是 burn rate 算不准，还是没人会配？）
3. 全量留痕的 cardinality 你们怎么扛的——recording rules？降采样？分库？
4. 一人值班 vs 多人轮值，你们「该收敛多少」的分界线到底在哪？

最好带一个「收敛后漏报」或「全量后疲劳」的真实案例，我们一起拆。