查不到昨天CPU数据是因为sysstat服务未运行、日志文件缺失或cron未配置采集；需验证服务状态、检查saXX文件存在性、确认cron任务启用；sar -f必须置于选项最前才能读取历史数据。
查不到昨天的 CPU 数据？先确认 sysstat 是否真在存
不是 sar 不行，是没人给它存数据。默认情况下，sar 只能读取 /var/log/sysstat/saXX（如 sa14 表示 6 月 14 日）里的二进制归档，而这些文件由 sysstat 的后台服务生成。
执行以下三步快速验证：
-
systemctl is-active sysstat—— 必须返回active，否则服务没跑 -
ls -l /var/log/sysstat/sa$(date -d yesterday +%d)—— 比如今天 6 月 14 日，就查sa13；若报 “No such file”，说明昨天根本没采集 -
grep -v "^#" /etc/cron.d/sysstat | grep sa1—— 确保有类似*/10 * * * * root /usr/lib/sa/sa1 -S DISK 1 1的行，且未被注释
Ubuntu/Debian 安装后常默认禁用，得手动 sudo systemctl enable --now sysstat；最小化系统或容器里 cron 缺失，sa1 根本不会触发。
sar -u -f /var/log/sysstat/sa13 这样写才对
-f 是读历史数据的唯一入口，但它必须放在所有其他选项**前面**，顺序错了就当没写。
正确姿势：
- 查 6 月 13 日 CPU 使用率：
sar -f /var/log/sysstat/sa13 -u - 加细分项（比如看软中断）：
sar -f /var/log/sysstat/sa13 -u ALL - 限定时间段（注意时间必须对齐采样粒度，默认 10 分钟）：
sar -f /var/log/sysstat/sa13 -u -s 14:00:00 -e 15:00:00
常见错：
-
sar -u -f /var/log/sysstat/sa13——-f在后面，sar会忽略它，转而读当天缓存 -
sar -u 13—— 这会被解释为“每 13 秒采一次”，和日期无关 -
cat /var/log/sysstat/sa13—— 二进制文件，直接 cat 是乱码，必须用sar -f或sadf解析
%iowait 高 ≠ 磁盘慢，%idle 高也不代表不卡
sar -u 输出里最易误读的是 %iowait 和 %idle：
-
%iowait > 30%持续出现，大概率是存储响应慢（NFS 卡顿、RAID 降级、本地盘故障），但前提是 CPU 真空闲——如果此时%idle也很高，那确实是 I/O 等待；如果%idle很低，%iowait高就可能是统计偏差或内核 bug -
%idle低但系统不卡？可能单核饱和（用sar -P ALL -f /var/log/sysstat/sa13查各核） -
%idle高但系统卡死？立刻ps aux | grep ' D '，找不可中断睡眠进程（D 状态），通常是存储设备无响应
别只盯 %user + %system，真正有意义的 CPU 忙碌占比是 100 - %idle。
想定位卡顿发生时刻，别扫全量，要分层筛
原始 sar -u -f /var/log/sysstat/sa13 输出每行是 10 分钟一个点，靠肉眼翻很难抓到异常时刻。
高效做法：
- 先用
awk快速筛出%idle异常低的行：sar -f /var/log/sysstat/sa13 -u | awk '$6 （<code>$6是%idle列，依实际列序调整） - 再针对可疑时间段做精细截取：
sar -f /var/log/sysstat/sa13 -u -s 14:30:00 -e 15:00:00 - 交叉验证：同一时间跑
sar -r -f /var/log/sysstat/sa13（内存）、sar -b -f /var/log/sysstat/sa13（IO 吞吐），看指标是否同步尖刺
默认 10 分钟粒度会漏掉秒级毛刺；真要抓瞬时峰值，得提前配置 sa1 每秒采样（如 */1 * * * * root /usr/lib/sa/sa1 1 1），否则只能靠 top 或 pidstat 临时补位。
