上周运维同事老张半夜被短信炸醒，一看是服务器 CPU 突然飙到 98%，结果连上系统发现只是某台测试机在跑压测脚本——告警没做过滤，纯靠运气判断真假。这事儿挺典型：告警不是设了就完事，关键在“实时”和“有用”两个字上。
别把告警当摆设
很多团队装了 Zabbix、Prometheus 或阿里云云监控，一通配置后就扔那儿不管了。结果要么三天两头弹窗刷屏（比如磁盘使用率每小时超 85% 就告），要么真出问题时静悄悄。实时告警的核心不是“快”，而是“准”——在正确的时间，用正确的渠道，告诉正确的人，一件真正需要处理的事。
几个马上能改的小动作
1. 加个冷静期（cool-down）
比如 Redis 连接数突增，连续 3 次检测都超阈值再发告警，而不是每次采样都触发。Prometheus 的 alert_rules.yml 里可以这样写：
expr: redis_connected_clients > 1000
for: 2m
labels:
severity: warning
annotations:
summary: "Redis 连接数过高"2. 分级推送，别一股脑塞微信
小问题推企业微信/钉钉群（如：Nginx 5xx 错误率 5 分钟内超 1%）；严重故障必须电话+短信双触达（如：核心数据库主从断连超 30 秒）。Zabbix 里可以在 Action 里按 trigger severity 设置不同 media type。
3. 给告警带上上下文
别只写“磁盘快满了”，改成：“server-03 (/var/log) 使用率达 94%，最近 2 小时日志增长 1.2G，疑似 cron 日志未轮转”。一行命令就能加信息：
df -h | grep '/var/log' | awk '{print $5,$1}'真实场景参考
我们给一家做 SaaS 的客户调过告警策略：之前他们所有 API 响应时间 >2s 就告警，每天收 87 条，没人点开看。后来改成——只对 /pay/submit 和 /order/create 这两个关键路径，且错误码为 500 + P95 耗时 >3s，持续 1 分钟以上才触发。一个月下来，有效告警剩 3 条，全部在 5 分钟内定位到慢 SQL。
实时告警不是拼谁设得快，而是拼谁想得细。多问一句“这个告警来了，我下一步具体要做什么”，答案往往就藏在阈值、持续时间、标签和通知渠道的组合里。