查凌晨死机原因关键在于确认sysstat服务是否启用并留存历史数据，需先验证服务状态、检查saxx归档文件是否存在、确认配置enabled="true"，再结合cpu软中断、i/o等待、内存oom等指标定位异常。
要查凌晨死机原因，关键不是“运行sar”，而是确认系统当时是否真有记录——sar本身不自动存历史数据，必须提前启用sysstat采集服务。如果没开，再怎么查也是一片空白。
先确认历史数据是否存在
死机发生在凌晨，首先要验证那天的数据有没有被采集到：
- 检查sysstat是否启用：运行sudo systemctl is-active sysstat，返回
active才算在运行；若为inactive，说明根本没存过任何历史数据 - 查看对应日期的归档文件：比如死机是7月18日凌晨，执行ls -l /var/log/sysstat/sa18（注意是
sa18，不是sa018或sa18.log）；若文件不存在，大概率是服务未启用或cron没执行成功 - 确认配置已生效：检查/etc/default/sysstat（Ubuntu/Debian）或/etc/sysconfig/sysstat（RHEL/CentOS），确保
ENABLED="true"且未被注释
定位死机发生时段的关键指标
凌晨异常往往表现为资源耗尽或硬件响应停滞，重点看这几项：
-
CPU软中断飙升：执行sar -u ALL -f /var/log/sysstat/sa18 | grep -A5 "2:00:00"（替换为实际死机时间附近，如
02:30:00），关注%soft是否持续高于20%——常见于网卡收包风暴或驱动异常 -
I/O等待严重：用sar -u -f /var/log/sysstat/sa18 -s 02:00:00 -e 03:00:00截取时段，若
%iowait > 30%且%idle极低，说明磁盘卡住，可能是硬盘故障或RAID降级 -
内存耗尽触发OOM：运行sar -r -f /var/log/sysstat/sa18 -s 01:45:00 -e 02:15:00，观察
kbmemused是否逼近kbmemfree，同时检查pgpgin/pgpgout是否突增——这是内存频繁换入换出的信号
交叉验证其他线索
单一指标可能误导，需结合多维度印证：
- 查进程和负载：用sar -q -f /var/log/sysstat/sa18 -s 02:00:00看
runq-sz（运行队列长度）是否长期> CPU核数，说明任务积压 - 查磁盘响应：执行sar -d -f /var/log/sysstat/sa18 -s 02:00:00 -e 02:30:00，关注
await（平均I/O等待毫秒数）是否超过100ms，持续高位即表明存储层异常 - 查网络异常：运行sar -n EDEV -f /var/log/sysstat/sa18 -s 02:00:00，留意
rxerr/s、txerr/s或coll/s是否突增，可能指向网卡或交换机问题
补救与预防措施
如果这次没数据，下次就得提前布防：
- 立即启用采集：设
ENABLED="true"后，手动触发一次sudo /usr/lib/sysstat/sa1 1 1，生成首个saXX文件 - 缩短采集间隔：编辑/etc/cron.d/sysstat，把
*/10 * * * * root /usr/lib/sysstat/sa1 1 1改为*/5 * * * * root /usr/lib/sysstat/sa1 300 1，实现5分钟粒度捕获 - 保留更久数据：修改/etc/sysconfig/sysstat中
HISTORY=28（默认7天），避免关键窗口被轮转覆盖
