告警阈值怎么设置合理
家里装了监控摄像头，手机App时不时弹出“网络延迟过高”提示，结果一看画面又挺流畅，这种“狼来了”的情况，多半是告警阈值设得太敏感。反过来，有些公司服务器已经卡得转不动了，监控系统却一声不吭，那是阈值设得太宽。到底该怎么拿捏这个度？
先搞清楚监控对象的行为规律
比如你家的宽带，晚上8点到10点是高峰期，ping值平时60ms，那段时间跳到120ms也正常。如果你把告警阈值定在80ms，那每天晚饭后手机都会响个不停。合理的做法是观察一周流量和延迟数据，找出日常波动范围，再往上留点余量。比如95%的时间里延迟不超过110ms，那就可以把阈值设成140ms，既避开常态波动，又能捕捉真正异常。
参考业务容忍度来定
公司用的是视频会议系统，如果丢包率超过3%就容易卡顿，影响开会，那告警阈值就得卡在2.5%左右，提前预警。但如果是内部文件同步服务，偶尔慢点没关系，可以放宽到8%再报警。关键是问一句：谁会受影响？能忍到什么程度？按实际体验反推数值，比拍脑袋定一个“看起来专业”的数字靠谱得多。
分层级设置，别只给“开/关”两种状态
单一阈值容易误事。更实用的做法是分三级：比如CPU使用率70%时发一条“注意”，85%发“警告”，95%才触发“紧急”。这样运维人员有时间逐步排查，不至于每次都得火急火燎登录服务器。家庭用户也可以借鉴，路由器温度60℃提醒“注意散热”，75℃才推送强提醒。
动态阈值更适合波动大的环境
有些工具支持动态基线，比如Zabbix或Prometheus，能自动学习历史数据，识别“今天周三晚上的高峰”和“上周日的闲时”之间的差异。开启这类功能后，系统会在每周同一时段自动调整判断标准，避免节假日空置时误报。配置示例如下：
threshold: dynamic_baseline
window: 7d
deviation_factor: 1.5
alert_on_spike_only: true意思是基于过去7天数据计算基准线，当当前值超过基准1.5倍标准差时才告警，且只对突增敏感，适合访问量有明显周期性的场景。
上线前做一次压力测试
新服务刚上，没历史数据参考怎么办？模拟真实负载跑一遍。用工具压测Web接口，看QPS到多少时响应时间开始飙升，数据库连接池何时耗尽。把这些临界点记下来，告警阈值设在临界值的80%左右。比如数据库最大支撑500连接，那380就该提醒，留出处理时间。
定期回顾，别设完就忘了
夏天来了，路由器放在电视柜角落，散热变差，同样的负载下温度比春天高了10℃。如果还用之前的温度阈值，可能天天报警。建议每季度翻一次告警规则，结合最近一个月的日志，看看哪些告警真有用，哪些成了“背景噪音”。删掉没人理的，优化频繁触发的。