必须先确认sysstat服务运行、enabled="true"且cron任务启用，否则sar -n dev -f无法读取历史网卡数据；查9月25日流量需用sar -f /var/log/sa/sa25 -n dev，-f必须置前，路径、文件名、权限均须严格匹配。
必须先确认 sysstat 是否在采集历史数据，否则 sar -n DEV -f 读出来的永远是空或报错。
检查 sysstat 历史采集是否启用
很多人以为装了 sar 就能查历史，其实它只是个“读取器”，背后靠 sysstat 的定时任务写入二进制数据。不启用采集，/var/log/sa/ 下压根没 saXX 文件。
- 运行
systemctl is-active sysstat，输出active才算服务在跑 - 检查配置：RHEL/CentOS 看
/etc/sysconfig/sysstat，Debian/Ubuntu 看/etc/default/sysstat，确认ENABLED="true" - 验证 cron 是否生效：
ls /etc/cron.d/sysstat应存在，且内容含类似*/10 * * * * root /usr/lib64/sa/sa1 -F -L的行 - 首次启用后需等至少一个采集周期（默认 10 分钟），才能生成首个
/var/log/sa/sa30（今天是 9 月 30 日）
用 sar -n DEV -f 查指定日期的流量突增
历史网卡数据只存日，不存年月，文件名严格为 saDD（如 sa25 表示本月 25 日），路径固定为 /var/log/sa/ —— 不是 /var/log/sysstat/，也不是其他变体。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查 9 月 25 日的流量：
sar -n DEV -f /var/log/sa/sa25，不是sa0925或sa20260925 -
-f参数必须放在所有选项**之前**，比如sar -f /var/log/sa/sa25 -n DEV有效，sar -n DEV -f /var/log/sa/sa25可能被忽略（取决于版本） - 非 root 用户执行时，因权限不足读
/var/log/sa/会静默失败（无报错、输出为空），加sudo或切 root 再试 - 想缩小范围看某一时段？得配合
-s和-e，例如sar -f /var/log/sa/sa25 -n DEV -s 14:00:00 -e 15:00:00
识别流量突增的关键字段和陷阱
sar -n DEV 输出的 rxkB/s 和 txkB/s 是 KB/s（1 KB = 1000 B），不是 bps；它统计的是 L2 层总字节数，含帧头、IP 头、TCP 头等，比应用层吞吐略高。
- 突增判断看峰值：单次采样中
rxkB/s > 5000或txkB/s > 5000已属异常（除非你在传大文件），结合rxpck/s是否同步飙升，可区分是大包还是小包洪流 - 接口名可能不一致：历史记录里的
ens33可能在当天重启后变成enp0s3，但sar仍按采集时刻的设备名存，不会映射；若输出只有lo没有物理网卡，说明当时该网卡未 UP 或sysstat启动晚于网卡激活 - 单位换算别搞错：686 KB/s × 8 ÷ 1000 = 5.488 Mbps（注意是 Mb，不是 MB），别用 1024 进制去算网络带宽
为什么查不到昨天的流量？常见静默失败点
查 sa29 却输出空，往往不是命令写错，而是底层链路断了。
-
ls /var/log/sa/sa29返回 “No such file”：说明 29 日没生成文件 → 检查那天sysstat是否宕过、cron 是否被禁、磁盘是否满（df -h /var） -
ls能看到sa29，但sar -f /var/log/sa/sa29 -n DEV无输出：大概率权限问题（非 root）、文件损坏（sar校验头时间戳失败）、或内核未开启网络统计支持（极少见） - 误用
sar -n DEV -s 10:00 -e 11:00不加-f：这查的是当天实时缓冲区，而缓冲区默认只存最近几分钟，早清空了 -
saXX是二进制格式，用cat或less打开只会输出乱码，必须用sar -f解析
真正卡住排查的，从来不是命令语法，而是 sysstat 是否真正在后台默默记账——一旦漏采一天，那段网络行为就彻底不可回溯。
