服务器故障提示；3个假报警最耽误排查

监控面板红得最热闹的那一刻，往往是机器最没事的时候。真把业务搞趴下的那条告警，一般安安静静躺在列表最底下，颜色还是灰的。服务器故障提示3个假报警最耽误排查——假报警本身不致命，致命的是它把人的注意力吃干净了，等你从一堆红字里抬起头，真凶早就跑远了。

探针自己先躺下，机器还站着

最常见的一类。Zabbix 的 agent、Prometheus 的 node_exporter，随便哪个进程被 OOM 干掉一次，面板立刻一片“实例不可达”。你冲到机房一看，机器风扇转得好好的，ssh 一登就进。这类报警跟服务器状态没关系，是采集链路断了。

还有一种更阴的：采集端时间没对齐。NTP 没配好，几台机器的时钟差出几分钟，两条本来八竿子打不着的事件，在时间轴上排成了“因果”。你顺着这个假因果查半天，最后发现是时钟的事。顺手瞄一眼 chronyd 或者 timedatectl 的状态，比什么玄学推理都强。

推送链路也算一类。邮件进了垃圾箱、短信通道欠费、webhook 的 token 过期——你以为“没报警就是没事”，报警根本没送到你眼前。值班交接时提一句这个，能省掉后面一堆误会。

阈值卡太死，正常波动也喊救命

CPU 到 80% 就报，可这台机器每天凌晨跑备份，那个点必到 90%。磁盘到 90% 就报，可 logrotate 压根没配，日志天天长。这种报警不算错，是阈值没跟着业务走。

还有个经典误会：free 一看内存快没了，慌张重启，实际大半是 buff/cache，available 还好好的。半夜被这条叫起来的人，我见过不止一个。

改法不复杂。告警加个持续时间，比如 for: 5m，抖一下就过去的不算数；阈值分时段，备份窗口单独一套；磁盘那条直接盯 inode 和增长速率，比盯百分比有用得多。

服务器故障提示3个假报警最耽误——把“业务慢”算成“机器挂”

用户一句“网站打不开”，值班的人第一反应就是服务器挂了。ssh 上去 top 一敲，负载 0.3，内存闲得发慌。机器好得很，慢的地方在别处：数据库一条慢查询把连接池占满、第三方支付回调卡住、CDN 回源超时，甚至就是 DNS 解析慢。

这类误判最耽误事，因为你盯着机器看，永远看不出问题。得分层排：本机资源 → 内网链路 → 出口带宽 → 第三方依赖，一层一层往下走，比在服务器上反复 top 高效得多。

顺手记一句，真故障往往是“组合拳”：CPU、连接数、磁盘 IO 一起不对劲。只有一个指标孤零零地跳，先怀疑监控本身。

报警发得越多，越没人看

一天几百条，人的反应不是更警觉，是直接静音。狼来了的故事在值班室里天天上演。更麻烦的是静音规则本身会变成新坑——半年前为了图清静关掉的那条，恰好就是这次真出事的那条。

所以告警要分级。能打电话叫醒人的，一晚上不该超过几条；剩下的进群、进工单、只入库。级别定完还得有人定期回头看，哪些规则一个月没触发过、哪些天天触发但从没出过事，该关就关。

三条土办法，先分清真假

第一，看时间轴对不对得上：多条告警是不是同一分钟冒出来的，采集端时钟是否一致。第二，看能不能复现：手动 curl 一下站点、ssh 上去 uptime、df -h 看一眼磁盘，两分钟能确认的事别在群里讨论半小时。第三，看历史基线：同一个时间点上周是不是也这样，每天固定时段出现的告警，八成是定时任务。

顺手能做的几件小事

每条告警后面加一句人话，写清“看到这条先干什么”。比如“实例不可达 → 先 ping 再 ssh，通了就查 agent”。值班的新人照着做就行，省下的就是自己的睡眠。

监控也别只盯机器。业务关键路径——登录、下单、支付回调——单独埋一条探针，机器再健康，这条不通也是白搭。定时任务、备份、证书到期这种“一定会发生”的事，提前提醒，别等它变成故障再说。

下次面板再红成一片，先别急着重启。按顺序过一遍：探针活没活、时钟齐不齐、阈值合不合理、业务链路哪一段堵了。这四步走完，多半你会发现，真正要动手的地方只有一处。