公司楼下的咖啡机坏了，没人发现，直到连续三天没人喝上咖啡。系统出问题也一样，等用户反馈才去查，早就晚了。与其被动救火，不如提前设好监控告警配置，让异常自动跳到你眼前。
告警不是越多越好
刚接手运维时，总想着把所有指标都加上告警，CPU、内存、磁盘、接口响应时间……结果半夜手机狂响，90%是误报。后来才明白，有效的监控告警配置，关键不在“全”，而在“准”。
比如一个服务的CPU使用率突然飙到85%，看起来挺吓人，但如果历史数据显示它日常就在75%-80%之间波动，那这个值其实正常。反而是一个平时只用20%的后台任务，某天突然持续占用50%，更值得警惕。
从场景出发设置阈值
别照搬网上的“最佳实践”。每个系统的负载模式不同，告警阈值得结合业务来定。电商系统在大促前一周，流量翻倍是常态，这时候还按平时的QPS阈值告警，只会让自己神经衰弱。
可以这样操作：先观察一周的运行数据，找出正常波动范围，再在这个基础上加个安全边际。比如平均响应时间是200ms，偶尔冲到400ms，那就把告警阈值设在600ms，持续超过3分钟再触发。
告警信息要能直接干活
收到一条告警：“服务器192.168.3.11 CPU过高”。然后呢？还得登录系统查进程、看日志，等搞清楚原因，十分钟过去了。好的告警配置，应该让你一眼就知道下一步动作。
比如改成：“【高优先级】订单服务节点 192.168.3.11 CPU 持续高于80%，最近5分钟有大量慢查询，建议检查数据库连接池”。信息明确，处理路径清晰，节省的是实实在在的时间。
用代码管理告警规则
在Web界面点点点配置告警，改几次就乱了。现在主流的做法是把告警规则写成代码，放在Git里统一管理。
以Prometheus为例，可以把告警规则定义在YAML文件中：
groups:
- name: example-alerts
rules:
- alert: HighCpuUsage
expr: rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.8
for: 3m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} CPU 使用过高"
description: "{{ $labels.instance }} 连续3分钟CPU使用率超过80%，请检查是否有异常进程。"
这样一来，谁改了规则、什么时候改的、为什么改，全部可追溯。新成员接手也方便，不用靠口头交代。
别忘了测试和静默
上线新告警前，先在测试环境模拟触发一次，看看通知能不能顺利到达手机。有时候配置写对了，但通知渠道没通，等于白搭。
还有就是维护窗口。计划内重启服务前，记得给相关告警加个静默（silence），避免凌晨三点被自己吓醒。很多团队都有过这种经历：明明知道要升级，还是被自己的告警吵起来，体验极差。
监控告警配置不是一劳永逸的事。业务在变，系统在长，每隔一段时间就得回头看看，哪些告警已经失效，哪些需要调整。把它当成日常巡检的一部分，比出事后再补强得多。