不能只靠 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 确认是否单个进程拖垮，还是多核并行负载正常。
