前两天同事老张急得满头大汗，说公司服务器出问题了，监控系统早就该发告警，可手机愣是没收到一条消息。结果等发现时，数据库已经挂了快一个小时。其实这种情况并不少见，很多人以为装了监控软件就万事大吉，但真出事时才发现——告警根本没通。
先查通知渠道有没有配置
最常见的原因，其实是压根没把通知方式设好。比如用 Zabbix、Prometheus 或者国产的夜莺监控，都需要手动添加邮箱、短信、微信或钉钉机器人。很多人只配了“邮件”，但公司的邮件服务器正好屏蔽了这类通知，或者直接进了垃圾箱。
建议多通道开启：比如同时绑定企业微信和短信，哪怕一个失效，另一个还能顶上。别图省事只留一种方式，就像不能把所有钥匙串在一把锁上。
检查接收人是否正确
有时候规则写的是“发给运维组”，但实际配置里这个组里一个人也没有。或者是你换了手机号，但系统里还是旧号码。我见过最离谱的一次，告警发给了一个离职三年的老员工。
打开你的监控平台，找到“用户管理”或“联系人组”，确认自己的账号在接收列表里，电话、邮箱、 webhook 地址都准确无误。
防火墙或网络策略拦了请求
有些告警是通过 HTTP 请求推送到钉钉或企业微信的，格式类似：
{"msgtype": "text", "text": {"content": "CPU 超阈值！"}}如果服务器处于内网，且没有配置 outbound 访问权限，这条请求根本出不去。这时候你在后台看“已触发告警”，但实际上消息卡在本地。
解决办法是让网络管理员放开对应域名的外访权限，比如 oapi.dingtalk.com 或 qyapi.weixin.qq.com，必要时走代理。
告警规则写错了
有些人设置的条件太严，比如“连续5次超80%才触发”，结果机器一直79.9%，告警永远不启动。或者时间窗口设得太长，等真出问题，通知延迟半小时才来。
还有种情况是表达式写反了，本该用 >= 结果写成 <=，导致系统正常时狂发告警，出问题反而安静了。
服务本身挂了或日志报错
登录监控服务器，看看告警模块的进程还在不在。比如 Prometheus 的 Alertmanager，经常因为配置文件语法错误直接起不来。可以查看日志：
journalctl -u alertmanager.service --since "5 minutes ago"如果看到 parse failed 或 connection refused，基本就是配置或网络问题。修复后重启服务，再手动触发一次测试告警。
做个定期自检
别等到真出事才想起检查告警系统。建议每个月搞一次“故障演练”：手动停掉一个非核心服务，看能不能收到通知。就像消防演习，平时练熟了，关键时刻才靠得住。
另外可以在手机上专门建个“告警测试”群，把各种通知往里发一遍，确保声音开着、不被静音、不会被其他消息淹没。