你有没有遇到过这样的情况？半夜手机突然震动，打开一看，用户投诉服务打不开了。一通排查下来，发现是服务器CPU跑满了，但其实在出问题前半小时，系统已经有异常征兆——只是没人知道。
监控不是摆设，告警要会“说话”
很多团队上了云平台，也配了监控，可还是频频被突发故障打个措手不及。问题不在工具，而在告警设置太“佛系”。比如，所有指标都用同一个阈值告警，结果每天收到几十条“警告”，时间一长，干脆把通知静音了。
真正的监控告警，得像小区的保安大叔——既不能见人就喊“有贼”，也不能等小偷搬空了才吭声。关键是要分场景、分等级、能追踪。
从CPU使用率说起
假设你在阿里云或AWS上跑着一个Web服务。可以设置当某台ECS实例的CPU连续5分钟超过80%时触发告警。但别忘了，高峰期短暂冲高是正常的，所以加个“持续时间”条件很重要。
{
"metric": "cpu_utilization",
"threshold": 80,
"duration": 300,
"comparison": ">",
"period": 60
}这段配置的意思是：每60秒检查一次CPU使用率，如果连续5次（即5分钟）超过80%，就发告警。这样既不会漏掉真实问题，也能避开毛刺干扰。
告警信息要“能看懂”
很多人只设置了“发送邮件”，内容却是默认的一串英文加ID。运维小李凌晨三点爬起来，还得先查这个Instance ID对应哪台机器。不如在告警模板里直接写清楚：
【高优先级】生产环境Web服务器 CPU过高
服务名称：user-api-prod-01
公网IP：47.98.123.45
当前CPU：89% (阈值80%)
发生时间：{{timestamp}}
查看图表：{{graph_url}}这样一目了然，连值班新人也能快速响应。
别让告警“单打独斗”
单一指标容易误判。比如内存占用高，可能是缓存正常工作；但如果同时看到请求延迟飙升、错误率上升，那才是真出事了。这时候应该组合多个信号。
你可以设置一个复合告警：当“HTTP 5xx错误率 > 5%”且“平均响应时间 > 1秒”持续2分钟，立即触发P1级告警，推送企业微信+电话呼叫。
测试你的告警系统
就像消防演习，告警系统也得定期“拉练”。可以故意停掉一个服务，看看是否在预期内收到通知。有些公司甚至搞“混沌工程”，随机杀掉容器来验证监控链路是否通畅。
有一次我们团队上线新告警规则后，没做测试。结果真正出问题时，发现通知渠道配置错了，整整20分钟没人收到消息。后来我们就定下规矩：每次改完告警策略，必须走一遍模拟流程。
告警也要“退休”
系统会迭代，告警规则也得更新。某个老服务下线了，对应的告警如果不清理，迟早会因为资源不存在而频繁报错，变成“狼来了”。
建议每季度做一次告警清单 review，关掉无效规则，合并重复项。就像整理衣柜，旧衣服该捐的捐，不然下次找关键告警时，翻半天都找不到。