用监控软件时，最烦两种情况：一种是半夜三点被一条‘CPU占用51%’的告警吵醒，一看啥事没有；另一种是服务器都卡成幻灯片了，系统还一声不吭。问题不在工具不好，而在于——你没调好告警灵敏度。
什么是告警灵敏度？
简单说，就是系统判断“出问题了”有多严格。灵敏度高，风吹草动都报；灵敏度低，非得等到快崩了才提醒。就像家里的烟雾报警器，厨房炒个辣椒就响，那是太敏感；油锅着火了还不响，那就是太迟钝。
常见场景怎么调？
比如你管着一台公司官网服务器。白天访问量大，CPU跑到70%很正常。如果你把告警阈值设在60%，那从早上九点开始，手机就得响个不停。这时候就应该把灵敏度调低点，比如改成连续3次采样超过80%再触发，避免误报刷屏。
反过来，数据库服务器平时负载很低，突然升到50%，可能就有异常查询或者连接泄漏。这种关键服务，就得把灵敏度调高，早点发现问题苗头。
结合时间策略更聪明
很多工具支持按时间段设置不同灵敏度。例如：
{
"service": "web_server",
"alert_rule": {
"working_hours": {
"cpu_threshold": 85,
"duration": "5m"
},
"off_hours": {
"cpu_threshold": 65,
"duration": "2m"
}
}
}上班时间阈值放宽，非工作时间收紧。这样既不影响日常运营，又能确保夜间的异常不会被忽略。
别忘了测试和观察
改完规则别撒手不管。先在测试环境跑几天，看新规则下有没有漏报或误报。也可以临时把通知发到测试群，等稳定了再切到正式告警通道。毕竟谁也不想因为调个参数，结果真出事时没人知道。
调灵敏度不是一锤子买卖。业务一变，流量模式一改，老规则可能就不适用了。定期翻翻告警记录，哪些是无效打扰，哪些是事后才发现的隐患，根据实际反馈持续优化，才能让系统提醒真正靠谱。