不能只靠 top 或 df 临时查问题，因异常有滞后性，单次命令抓不到趋势；长期监控需 sar 持续采集、基线对比与上下文分析，并确保告警链路可靠。
为什么不能只靠 top 或 df 临时查问题
因为异常往往有滞后性：磁盘缓慢填满、内存泄漏累积、I/O 队列悄悄变长，单次命令抓不到趋势。等 df -h 报出 95% 时，可能日志已轮转丢失、服务早开始超时。长期监控的核心不是“看到”，而是“比对”和“预警”——需要带时间维度的数据沉淀与基线对比。
sar 是最稳的长期数据采集底座
sar（来自 sysstat）默认每10分钟采一次系统快照，数据写入二进制文件（如 /var/log/sysstat/sa05），轻量、可靠、不依赖网络或外部服务。它不像 Prometheus 需要部署全套栈，也不像自写脚本容易因权限/路径/crontab 错误而静默失效。
- 启用前必须运行：
sudo systemctl enable sysstat && sudo systemctl start sysstat - 关键采集项建议：
sar -u 1 3（CPU）、sar -r 1 3（内存）、sar -d 1 3（磁盘 I/O）、sar -n DEV 1 3（网卡流量） - 查历史数据别用错日期：日志文件名是
saXX，XX 是当月日数（如 2 月 5 日对应sa05），不是星期几 - 注意：默认配置可能不采集磁盘详细指标（
-x扩展参数），需编辑/etc/sysconfig/sysstat（RHEL）或/etc/default/sysstat（Debian）开启DISKSTATS=true
异常判定不能只看阈值，得结合上下文
比如 /home 分区标称告警阈值为 50MB，但实际只有 4MB 可用空间——这说明配置错误本身已是异常源头，而非磁盘真满了。类似地，%util 持续 90% 不一定代表磁盘瓶颈，要看 await（平均等待毫秒）是否同步飙升；load average 高，得配合 ps aux --sort -pcpu 确认是否单个进程拖垮，还是多核并行负载正常。
- 文件系统监控脚本里，务必先校验
$EXCEPTIONS中的阈值是否合理（如用df -B1 /home | awk 'NR==2 {print $4}'获取真实可用字节数） - 远程批量监控时，避免所有机器共用同一份阈值：数据库服务器和日志归档机的磁盘健康标准应不同
- 健康状态标记（如 “ALERT”/“SAFE”）必须基于计算结果，而非硬编码字符串；否则修改逻辑时极易漏改输出分支
通知链路最容易断在“最后一百米”
脚本跑通、数据存下、阈值触发——但没人收到告警，等于没监控。常见断点：邮件被当垃圾、sendmail 未安装、SSH 自动登录密钥过期导致远程采集失败、display_output 函数里调用 mail 命令时未加 -s 主题参数导致发送静默失败。
- 测试通知必须走完整路径：从触发条件 → 生成告警文本 → 调用
mail或curl推送 → 确认手机/邮箱收到 - 避免单点依赖：邮件发不出时，至少保留本地告警日志（
echo "$(date): ALERT on /dev/sda1" >> /var/log/diskalert.log） - 对关键路径（如 SSH 登录远程主机），在脚本开头加
ssh -o ConnectTimeout=5 -o BatchMode=yes user@host exit &>/dev/null || { echo "SSH fail"; exit 1; }主动探活
ls -lt /var/log/sysstat/ 和 grep -r "ALERT" /var/log/ 反向验证，比写新功能更重要。 
