监控告警：从指标到行动
监控失效的标志不是「没有监控」，而是「告警来了没人理」。从指标到行动，中间隔着规则设计和信息密度两道工序。
指标分四层
| 层 | 例子 | 用途 |
|---|---|---|
| 用户体验层 | 首屏时间、接口 P99、下单成功率 | 判断「用户是否受影响」，告警主力 |
| 应用层 | 错误率、队列积压、缓存命中率 | 定位方向 |
| 资源层 | CPU、内存、磁盘、连接数 | 容量与预警 |
| 依赖层 | 第三方接口成功率与延迟 | 判断「是不是别人的问题」 |
排障时从上往下看：用户体验层先确认「是否有事」，下层找「事出在哪」。告警规则主要挂在第一层，下层指标做辅助。
告警规则的三个要求
1. 可执行。 每条告警都要能回答「收到后第一步做什么」。回答不了的不是告警，是噪音——比如「CPU > 80% 持续 10 分钟」在没有对应预案时毫无意义。
2. 有抑制与分级。 依赖挂掉时，关闭它的所有下游告警（否则一次故障炸出 50 条）。P0 打电话、P1 群通知、P2 日报汇总。
3. 有豁免窗口。 部署期、备份窗口的已知波动，用维护窗口静默，避免狼来了。
一个实用的 P0 示例
告警：下单成功率 5 分钟 < 95%（基线 99.5%）
第一步：看错误分布 —— 网关 5xx / 业务拒绝 / 超时
预案：链接（回滚手册 / 依赖状态页）
白盒与黑盒
- 黑盒拨测：从外部定时请求关键接口，验证「用户视角的可用性」。它不依赖内部监控，是最诚实的信号；
- 白盒指标：内部细节丰富但可能自我感觉良好。两者都有，以黑盒为准判断影响。
四个黄金信号
延迟、流量、错误、饱和度（Google SRE）。不知道监控什么时，从这四个起手覆盖核心服务，比堆几十个不明所以的指标有效。
最后一条：每季度做一次「告警回顾」——统计每条规则近期的触发次数与处理记录，触发多、无动作的规则删掉或降级。告警系统的质量，以「每条告警都值得看」为标准。