监控告警体系：监控指标设计、告警阈值设置、告警风暴处理

监控告警这件事，说简单也简单，说复杂也复杂。我见过太多团队，要么是告警多到没人看，要么是系统挂了半天才发现。说白了，监控告警体系的核心就三件事：该看什么、什么时候报警、报警了怎么办。今天咱们就聊聊这三个话题。

我刚带团队那会儿，有个新人特别热情，把服务器上能采集的指标全加上了。CPU、内存、磁盘、网络、进程数、文件句柄数……光一个节点就上百个指标。结果呢？告警风暴来了，真正的问题反而被淹没了。

我个人习惯，监控指标分四层就够了：

我的小技巧：每个服务只选5-8个核心指标。指标多了，人眼根本看不过来。你想想看，一个仪表盘上密密麻麻的曲线，你能一眼看出问题吗？

阈值设置是个技术活，也是个艺术活。我在项目中遇到过最典型的案例：某团队把CPU告警阈值设成了80%，结果每天半夜都在报警——因为他们的定时任务在凌晨跑。后来大家直接把告警屏蔽了，真出问题的时候反而没人知道。

阈值设置我建议分三步走：

先观察，再设置：新系统上线，先跑两周看看基线。别一上来就拍脑袋设阈值。
动态阈值优于静态阈值：比如用3-sigma算法，或者基于时间序列的预测。白天和晚上的流量不一样，阈值也应该不一样。
分级告警：别一上来就P0。我习惯分三级：
- P2（警告）：指标异常但服务可用，比如CPU超过70%持续5分钟。发个钉钉消息就行。
- P1（严重）：服务部分不可用，比如错误率超过5%。需要电话通知值班人员。
- P0（紧急）：服务完全不可用，比如所有节点都挂了。直接拉群，全员响应。

避坑指南：我曾经把P0告警阈值设得太低，结果半夜被叫起来三次，发现都是误报。后来我学乖了——告警一定要加持续时间条件。比如“CPU超过90%持续5分钟”才报警，而不是一超过就报。这样可以过滤掉很多瞬时的毛刺。

告警风暴，说白了就是系统出问题后，告警像雪崩一样涌来。我记得有一次，数据库主库挂了，结果从应用层到基础设施，上百条告警同时触发。值班同学手机直接被打爆，但真正的问题反而被淹没了。

处理告警风暴，我总结了三个原则：

依赖关系优先：如果数据库挂了，应用层的告警其实都是“果”而不是“因”。我建议在告警规则里加上依赖关系，比如“如果数据库不可用，则自动抑制应用层的告警”。
告警聚合：别一条一条发。把相同类型的告警合并成一条，比如“有15台机器CPU超过90%”，而不是发15条告警。
告警降噪：设置告警静默期。同一个指标在10分钟内只发一次告警，避免重复轰炸。

  核心思路：告警的目的是让人发现问题，而不是让人处理告警本身。如果告警本身成了问题，那这个体系就是失败的。

下面这张图，是我对监控告警体系的理解。你可以把它当成一个思维导图来看：

最后，分享几个我踩过的坑，希望能帮你少走弯路：

别迷信“全自动”：自动恢复听起来很美，但有时候自动重启反而会掩盖真正的问题。我建议自动恢复只用于已知的、可复现的场景，比如OOM后自动重启。未知问题还是让人工介入。
告警要有上下文：别只发一条“CPU过高”。要带上时间、机器IP、当前值、阈值、以及最近5分钟的趋势图。这样值班同学一眼就能判断严重程度。
定期演练：我每季度会做一次“告警攻防演练”——故意制造故障，看看告警能不能正确触发，值班同学能不能正确处理。嗯，第一次演练的时候，我们发现了十几个问题。

一个小建议：告警不是越多越好，而是越准越好。我见过最优秀的团队，一个核心服务只有3条告警规则，但每条都能精准定位问题。你想想看，如果你的告警列表超过10条，是不是该考虑优化了？

好了，监控告警体系就聊到这儿。记住一句话：告警的目的是让人睡个好觉，而不是让人睡不着觉。如果你的告警体系让你天天失眠，那一定是哪里出了问题。