监控告警不触发？别急，先查这几块
前两天同事老李值班，凌晨三点被电话叫醒，说线上订单系统挂了。一查，CPU 直接飙到100%，但奇怪的是，监控平台一点动静没有。这下可炸锅了——明明配了阈值超过80%就发短信告警，怎么一声不吭？
这种情况其实不少见。监控系统看着稳如老狗，真出事却哑火，问题往往出在几个容易忽略的细节上。
1. 规则写错了，告警当然不会来
最常见的就是告警规则配置错误。比如你想监控服务器内存使用率，写了个条件：当 usage > 80 触发。但实际采集的数据字段叫 mem_usage，结果条件永远不成立。
还有些人复制别人的模板，没改通知方式。规则是设了，但接收人填的是离职员工的邮箱，或者 webhook 地址指向了一个已经停用的钉钉群。
2. 数据根本没上来，告警自然没得发
告警依赖数据采集。如果 agent 挂了、网络不通、防火墙拦了端口，数据断了，再灵敏的规则也白搭。
曾经有个案例，一台新上线的数据库服务器忘了装 zabbix-agent，监控面板显示“无数据”，但没人注意。连续一周 CPU 跑满，告警始终沉默。后来才发现，不是告警不触发，而是它压根不知道这台机器的存在。
3. 阈值设置太激进或太保守
有人怕误报，把 CPU 告警设成95%以上持续5分钟才通知。可现实是，服务一出问题，CPU 瞬间拉满，两分钟后自动重启恢复。这个“瞬间”没达到持续时间，告警就被过滤掉了。
反过来，有些人设得太敏感，1分钟内请求失败率超10%就报警。结果每次发布版本都响一次，大家习惯了当“狼来了”，真有问题也麻木了。
4. 告警风暴熔断机制反向背锅
有些系统自带防刷功能，比如一个小时内同类型告警只发一次。听起来合理，但遇上持续性故障，第一次通知后，后续完全静音，值班的人还以为问题解决了。
更坑的是，某些平台默认开启“告警抑制”，A 服务挂了引发 B、C 连环告警，结果只显示一条，其他被归为“关联事件”，藏在二级页面里，没人会去翻。
5. 时间不同步也能导致告警失效
服务器时间和监控服务器差了十分钟，可能导致告警判断的时间窗口错位。比如你设的是“最近5分钟平均负载”，但两边时间对不上，采集的数据段和判断逻辑对不齐，条件始终不满足。
这种问题查起来特别费劲，因为所有配置看起来都没错，最后发现是 NTP 同步崩了。
6. 测试不能偷懒
新上一套监控，很多人配完就完事，从来不测试。正确的做法是：模拟一次真实故障，比如手动把某个服务 kill 掉，看会不会收到告警。
我们组现在有个规矩：任何新的告警规则上线，必须走一遍真实触发流程，截图留证，才算闭环。
一个简单的检查清单
遇到告警不响，可以按这个顺序快速排查：
- 确认监控 agent 是否运行
- 检查目标主机是否在监控列表中且状态为“活跃”
- 查看最近是否有数据上报
- 核对告警规则中的指标名称、阈值、持续时间
- 确认通知渠道（邮件、短信、webhook）配置正确
- 检查系统时间是否同步
- 手动触发一次异常，观察日志和通知记录
监控不是设完就高枕无忧的事儿。它像家里的烟雾报警器，装了不代表永远有效。定期“按一下测试键”，才能确保关键时刻不掉链子。