必须先确认sysstat已安装且采集服务启用：用which sar或rpm/dpkg检查安装，再查/etc/default/sysstat或/etc/sysconfig/sysstat中enabled="true"，并验证cron/systemd任务运行及首个saxx文件生成。
确认sysstat是否已安装且服务启用
没装sysstat，sar命令根本不存在；装了但ENABLED="false"，就只能实时采样，查不到历史数据。必须分两步验证：
- 检查是否安装：
which sar或rpm -q sysstat（RHEL/CentOS）、dpkg -l sysstat（Debian/Ubuntu） - 检查是否启用采集：
- Debian/Ubuntu：确认
/etc/default/sysstat中ENABLED="true" - RHEL/CentOS：确认
/etc/sysconfig/sysstat中ENABLED="true"
- Debian/Ubuntu：确认
- 检查
cron或systemd是否真在运行采集任务：ls /etc/cron.d/sysstat（存在且含/usr/lib*/sa/sa1行），或systemctl is-active sysstat返回active
首次启用后，需等待至少一个采集周期（默认 10 分钟）才会生成首个/var/log/sysstat/saXX文件。
查不到/var/log/sysstat/saXX？先看文件是否存在
sar -f后面跟的必须是完整、存在的二进制文件路径，不是目录，也不是随便写的日期。常见错误包括：
-
sar -u -f /var/log/sysstat/→ 缺少具体文件名，报No such file or directory -
sar -u -f /var/log/sysstat/sa25→ 今天是 9 月 28 日，sa25对应本月 25 日，如果系统刚启用采集，25 号文件可能还没生成 -
sar -u -f /var/log/sysstat/sa05→sa05永远指当月 5 日，不是上月 5 日，别按日历直觉脑补
正确做法是先列出当前可用的历史文件：ls -t /var/log/sysstat/sa[0-9][0-9]。只显示两位数日期的saXX文件，不包含sarXX（那是文本报告）或saYYYYMMDD（需显式配置-D才启用）。
用对sar参数才能看到想查的指标
sar不同选项对应完全不同的内核数据源，参数错一个，输出字段就全不对——而且不报错，容易误判为“数据异常”。关键匹配关系如下：
- CPU 使用率：
sar -u -f /var/log/sysstat/sa28→ 输出%user、%system、%iowait、%idle - 内存使用：
sar -r -f /var/log/sysstat/sa28→ 看%memused、kbmemfree、kbbuffers - 磁盘总体吞吐：
sar -b -f /var/log/sysstat/sa28→ 关注tps、rd_sec/s、wr_sec/s - 单个磁盘延迟与队列：
sar -d -p -f /var/log/sysstat/sa28→ 必须带-p才显示设备名（如sda），否则只显示数字编号
saXX是二进制格式，不能用cat或less打开；强行读只会看到乱码，还可能触发终端编码错误。
历史数据能存多久？别指望默认配置撑过一个月
/var/log/sysstat/下的文件保留天数由HISTORY变量控制，默认值通常是28（见/etc/sysconfig/sysstat或/etc/default/sysstat）。这意味着：
- 今天是 9 月 28 日，
sa01（9 月 1 日）大概率已被轮转删除 - 若需保留更久，必须手动改
HISTORY=90并重载服务（systemctl restart sysstat），但要注意磁盘空间 - 旧文件被压缩后（如
sa01.gz），sar -f无法直接读取，得先gunzip解压
最易被忽略的一点：saXX文件是按本地时区生成的，跨时区迁移服务器或修改系统时间后，saXX与实际日期可能错位——此时得结合file /var/log/sysstat/saXX或sadf -d /var/log/sysstat/saXX | head -n1确认真实采集时间戳。
