你装了监控系统，仪表盘很漂亮，彩色曲线在屏幕上跳动。然后你把它关了，再也没打开过。
监控的价值在于告警，不在于仪表盘。没有告警的监控只是装饰。你不可能24小时盯着屏幕，但系统可以替你盯着。
今天不讲具体工具怎么配，讲告警配置的方法论——阈值设多少、怎么分级、怎么避免被告警疲劳压垮。
先看一个数据
运维团队的工作量里，告警处理占了很大一部分。但如果告警配置不合理，大量无效告警会淹没真正重要的通知，导致关键故障被忽略。这就是告警疲劳。
告警配置的核心不是“把所有异常都通知出来”，而是“在正确的时间通知正确的人”。
告警分级：什么级别该通知谁
告警分三级就够了：紧急（P0）、警告（P1）、信息（P2）。每一级的通知方式、响应时间、处理人都不同。
P0——紧急：需要立即响应
服务不可用、核心功能受损、数据丢失风险。这类告警需要立即响应，通常由值班运维处理。通知方式：电话、短信（最可靠）。响应时间：5分钟内。
P0告警发出后10分钟没有确认，自动升级通知到更高级别负责人。避免关键告警被遗漏。
P1——警告：需要当天处理
服务可用但性能下降，CPU持续高负载、磁盘即将写满、SSL证书即将过期。这类告警不要求立即处理，但需要当天内响应。通知方式：钉钉/企业微信、邮件。响应时间：4小时内。
P2——信息：记录即可
非关键指标波动，如开发环境的告警、偶发的异常峰值。通知方式：邮件或日志记录，不主动推送。人工定期查看即可，不需要即时通知。
告警阈值：什么数值算异常
CPU使用率：持续超过80%触发P1警告，超过95%触发P0紧急。不要设置为单次超过即告警，瞬时峰值不代表问题。建议设置持续时长，如“持续5分钟超过80%”再触发告警。
内存使用率：持续超过85%触发告警。可用内存低于总内存15%时，系统性能明显下降。如果发现内存持续增长，可能是内存泄漏，需排查。
磁盘使用率：超过85%触发P1警告，超过95%触发P0紧急。磁盘写满通常是不可逆的，需要在写满前处理。告警阈值建议设在80%就提前通知，给运维留出清理时间。
服务探活：应用健康检查接口连续3次失败（间隔10秒）触发P0紧急。服务不可用是最高优先级，需要第一时间通知。
SSL证书有效期：小于30天触发P1警告，小于7天触发P0紧急。证书过期是计划内可预见的故障，提前30天通知有充足时间处理。
避免告警疲劳：告警不被忽略的几个原则
告警被忽略通常不是因为运维不上心，而是告警太多了。以下几条设计原则帮你避免过度告警：
重复告警抑制：相同告警在30分钟内只发送一次。服务器CPU持续高负载，不需要每5分钟发一次通知。
关联告警聚合：服务器宕机时，不要同时发送CPU、内存、磁盘、网络4条告警。合并成一条“服务器不可用”就够了。
静默窗口：凌晨2点到6点的P1告警静默，聚合为次日早报。半夜被叫醒处理非紧急问题，对运维体力消耗很大。
告警分级：严格按照P0/P1/P2分级，不要把所有异常都设成紧急。P0只留给真正的故障。
告警后续行动：从告警到问题闭环
告警发出后，真正的工作才刚刚开始。每次告警处理完后，记录三件事：
- 根因是什么？
- 恢复耗时多久？
- 需要做什么前置措施避免再次发生？
如果同一类告警重复出现，说明问题没有真正解决。要么调整系统配置，要么优化代码，要么修改阈值。告警不是用来“看到”的，是用来“推动行动”的。
一个真实案例
一家公司运维配置了CPU告警，阈值设为70%，单次超过即触发。每天收到几十条告警，大部分是瞬时峰值。运维人员开始忽略这些告警，最终一次真正的CPU故障被淹没在告警洪流中。后来告警策略调整为“持续5分钟超过85%”才触发，告警数量减少90%，关键故障得到了关注。
最后一句
告警配置不是“越多越好”。告警数量应该和团队处理能力匹配。一周几百条告警的监控系统，和没有监控系统差不多——真正出问题的时候，你根本不知道是哪一条。先定级，再设阈值，然后持续优化告警规则。好的告警配置让你在故障发生前收到通知，而不是在用户投诉后才开始排查。