先看现象。自研巡检脚本每天跑一遍，输出全是正常，一周后一台机器因为 inode 用满挂掉，脚本里只检查了 CPU、内存和磁盘使用率三项。
这类报错背后常见的原因有几处，逐个排除就行。采集项只覆盖 CPU 内存磁盘，缺 inode 和句柄。也可能是阈值写死，没有按机器规格区分。
少数情况下是结果不落库，历史无法对比趋势。
不容易想到的是，异常被脚本吞掉，退出码永远是零。
补上 inode、句柄、连接数检查
df -i / && cat /proc/sys/fs/file-nr然后让异常时返回非零并触发告警
bash -n /opt/scripts/inspect.sh && /opt/scripts/inspect.sh; echo $?每次结果按日期存档便于对比
mkdir -p /var/log/inspect && /opt/scripts/inspect.sh > /var/log/inspect/$(date +%F).log剩下的就是确认定时执行与退出码处理
crontab -l | grep inspect怎么算真的好了，看的是同一批现象。人为造一个 inode 紧张的场景，巡检脚本能报出来并返回非零，告警通道收到通知。
提醒一点。巡检的价值在覆盖面和可对比，不在输出好看；每出一次故障就往脚本里补一条检查项，比一次写全更实际。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。