Centos运维使用sar收集历史性能数据用于故障复盘

CentOS 运维人员在面对系统卡顿、服务异常或宕机事故时，最怕的就是没有任何历史数据可供回溯。故障发生的瞬间往往来不及手动敲命令，等你连上服务器时，负载可能已经恢复了正常。要解决这个痛点，最直接有效的方法就是把 sar 配置成一套持续采集历史性能数据的后台服务，让系统像飞机的黑匣子一样，把 CPU、内存、I/O 和网络的关键指标按时间轴完整记录下来。这样无论故障发生在凌晨几点，事后都能精确复盘到那一分钟的瓶颈所在。

sar 命令并不是独立存在的，它来自 sysstat 软件包。在 CentOS 上默认可能只安装了基础工具，需要确认 sysstat 是否完整安装。运行 rpm -q sysstat 可以检查版本。如果没有安装，直接通过 yum install sysstat -y 完成部署。安装完成后，核心的配置文件位于 /etc/sysconfig/sysstat，这个文件控制着历史数据保留多久以及采集间隔是多少。很多人忽略了这一步，直接用默认值，结果发现只能看到当天的数据，一周前的故障根本无从查起。打开这个文件，重点关注两个参数：HISTORY 定义了日志保留天数，默认是 28，建议根据磁盘空间调整到 60 或更长；COLLECT 如果设置为 false，历史采集功能根本不会启动，必须确认它是 true。

sysstat 包安装后会在 /etc/cron.d/sysstat 下生成定时任务文件。这个文件里通常包含两条任务：一条负责每 10 分钟执行一次数据采集，调用 /usr/lib64/sa/sa1；另一条负责每天凌晨做一次数据汇总，调用 /usr/lib64/sa/sa2。sa1 是采集脚本，它把当前性能快照写入 /var/log/sa/saDD 二进制文件中，DD 对应日期。sa2 则把当天的二进制数据转换成可读的文本报告，存入 /var/log/sa/sarDD。如果发现 /var/log/sa 目录下只有几天的文件，多半是 crond 服务没启动或者路径权限有问题。检查 crond 状态用 systemctl status crond，确保它在运行。日志目录的权限需要让 root 可写，通常 755 即可。

默认每 10 分钟采集一次对于偶发性的性能抖动来说太粗糙了。故障可能只持续 2 分钟，10 分钟的采样间隔大概率会错过峰值。要修改这个频率，不要直接改 cron 文件里的参数，因为 yum 更新 sysstat 时可能会覆盖。更稳妥的做法是在 /etc/cron.d 下新建一个自定义任务文件，或者直接修改 /etc/crontab 添加一行，例如把采集间隔缩短到 2 分钟：

*/2 * * * * root /usr/lib64/sa/sa1 1 1

sa1 后面两个参数，第一个 1 表示采集间隔秒数，第二个 1 表示采集次数。这里用 1 和 1 是因为 cron 已经控制了每 2 分钟触发一次，每次只采集一个样本即可。注意缩短间隔会增加日志文件体积，/var/log/sa 目录要预留足够空间。一般每天产生的二进制文件在默认间隔下约几百 KB，改为 2 分钟后可能增长到几 MB，磁盘规划时留出 2-3GB 比较安全。

数据存下来了，复盘时最常用的就是通过 -f 参数指定历史文件路径。比如要查看 3 月 15 日全天的 CPU 使用情况，命令是 sar -u -f /var/log/sa/sa15。输出会按采集时间点逐行显示用户态、系统态、iowait 等指标。如果想看某个时间段，用 -s 和 -e 指定开始和结束时间，格式为 HH:MM:SS。例如只看下午 2 点到 3 点之间的数据：sar -u -s 14:00:00 -e 15:00:00 -f /var/log/sa/sa15。这个功能在复盘时极其关键，能把问题锁定到分钟级。

CPU 复盘最怕只看整体使用率。sar -u 输出的 %user、%system、%iowait 和 %idle 需要结合起来分析。如果 %iowait 持续高于 10%，说明 CPU 在等待磁盘 I/O，这时候盲目升级 CPU 是没用的，瓶颈在存储。%system 过高通常意味着内核态操作频繁，可能是大量系统调用或上下文切换导致，这时候要用 sar -w 查看上下文切换率，sar -q 查看运行队列长度。运行队列长度如果持续大于 CPU 核心数，说明进程在排队等待调度，这才是真正的 CPU 瓶颈。复盘时把这些指标放在同一时间轴上对比，能快速判断是计算密集型任务还是 I/O 密集型任务拖垮了系统。

很多运维看到 free 命令中 available 很低就认为内存不足，但在复盘历史时，sar -r 输出的 kbmemfree、kbbuffers、kbcached 需要正确解读。Linux 的内存管理策略是尽可能利用空闲内存做缓存，所以 kbmemfree 很小不一定是问题。真正需要警惕的是 kbmemused 减去 buffers 和 cached 后的实际使用量持续接近物理内存上限，同时 sar -B 显示的 pgpgin 和 pgpgout 大幅增加，这说明系统在频繁进行内存换页，此时性能会急剧下降。sar -S 可以查看交换空间使用情况，如果观察到 %swpused 从 0 开始逐渐上升，说明物理内存确实不够了，进程开始被交换出去，这往往是 OOM 的前兆。

磁盘 I/O 是故障复盘中最容易误判的环节。sar -b 给出的是块设备的整体读写速率，sar -d 则可以精确到每个磁盘设备的 IOPS、平均响应时间和队列深度。复盘时如果发现 await 平均等待时间超过 20 毫秒，对机械盘来说还算正常，但对 SSD 就是严重异常。svctm 如果接近 await，说明磁盘本身处理能力饱和；如果 await 远大于 svctm，说明 I/O 请求在队列中等待时间过长。结合 sar -u 中的 %iowait，三个维度交叉验证，就能确定是磁盘硬件瓶颈还是应用层发起了不合理的 I/O 模式。比如数据库的随机读写突然增大，会直接反映在 /dev/sdb 的 IOPS 曲线上。

sar -n DEV 可以回溯每个网卡的收发字节数和包数，但仅看流量大小远远不够。sar -n EDEV 提供的是错误包、丢弃包的统计，这才是网络问题的核心。如果 rxdorp 或 txdrop 在某个时间点突然增加，说明网卡缓冲区溢出，可能是瞬间流量冲击或者网卡驱动处理不过来。sar -n TCP 中的 retrans/s 是 TCP 重传率，这个值如果超过 1%，网络质量就已经在影响应用响应时间了。复盘时把重传率曲线和应用日志中的超时错误时间点对应起来，往往能直接定位到网络设备或线路问题。

sar 的文本输出虽然直观，但要做跨天对比或者导入图表工具就不方便了。sadf 是 sysstat 包中的另一个实用工具，它可以把 sa 二进制文件转换成 XML、JSON 或 CSV 格式。例如 sadf -d /var/log/sa/sa15 — -u 会输出带时间戳的 CPU 数据，字段以分号分隔，可以直接导入 Excel 或 Python 的 pandas 做统计分析。复盘复杂故障时，用 sadf -j 输出 JSON 格式，然后写脚本把多天的数据合并，画出趋势图，比肉眼逐行扫文本高效得多。sadf 还支持 -T 参数指定显示的时间范围，用法和 sar 的 -s -e 类似。

光有历史数据还不够，如果每次都是等用户投诉再去翻日志，仍然是被动响应。可以在每天的 sa2 汇总脚本之后追加自定义分析逻辑。比如写一个 Python 脚本，用 sadf 解析当天的 sar 数据，检查 %iowait 是否超过阈值、重传率是否异常，一旦发现异常点就发送告警并自动截取前后 30 分钟的数据打包保存。这样即使故障发生在半夜，第二天上班时也能第一时间收到通知并拿到完整上下文。这种机制不需要引入额外的监控系统，完全基于 sysstat 自带的工具链就能实现，对于中小规模环境非常实用。

/var/log/sa 目录下的文件会随着时间积累，虽然 sysstat 配置中设定了 HISTORY 天数，但实际清理是由 /usr/lib64/sa/sa2 脚本在每日汇总时执行的。如果磁盘空间紧张，可以手动调整这个脚本中的保留逻辑，或者通过 logrotate 增加一层兜底。另外要注意，sa 文件是二进制格式，不能用文本编辑器查看，必须通过 sar 或 sadf 读取。备份时直接复制整个 /var/log/sa 目录即可，迁移到其他服务器后同样可以用 sar -f 读取，兼容性很好。对于需要长期归档的场景，建议用 sadf 转换成 CSV 后压缩存储，既节省空间又便于后续检索。

当管理的 CentOS 服务器数量增多时，逐台登录查看 sar 历史数据效率太低。可以利用 sysstat 的远程采集能力，在一台中心服务器上通过 SSH 免密登录批量拉取 sa 文件，或者在各节点上部署一个简单的 rsync 任务，把每天的 sa 文件同步到集中存储。更进阶的做法是用 sadf 输出 JSON 后直接写入时序数据库，配合 Grafana 做可视化。这样所有服务器的历史性能数据都在一个仪表盘上呈现，复盘时拖动时间轴就能看到全局状态，大幅提升故障定位速度。

假设某次业务高峰期出现间歇性响应变慢，持续约 15 分钟后自动恢复。复盘时首先锁定时间段，用 sar -u -f 查看 CPU，发现 %iowait 在问题时段飙升到 35%，而 %user 和 %system 都不高。接着用 sar -d -f 查看磁盘，发现 /dev/sda 的 await 从平时的 2 毫秒暴涨到 80 毫秒，同时 IOPS 并没有明显增加，说明不是读写量变大，而是单次 I/O 延迟变大。再用 sar -b 确认这段时间的块设备吞吐量反而下降了，符合磁盘处理能力下降的特征。最后检查硬件日志，发现该时段 RAID 卡触发了电池校准，导致写缓存被禁用。整个分析过程完全依赖 sar 的历史数据，不需要在故障发生时在线排查。

CentOS 7 和 CentOS 8 自带的 sysstat 版本不同，部分 sar 参数有差异。CentOS 7 的 sysstat 10.x 版本中，sar -d 输出的设备名可能是 dev8-0 这样的格式，需要配合 lsblk 映射回实际设备。CentOS 8 及后续的 sysstat 11.x 版本已经直接显示设备名。另外，较新版本增加了 sar -m 查看电源管理信息、sar -H 查看大页内存使用等，复盘时可以按需选用。如果从 CentOS 7 迁移到更高版本，旧的 sa 文件依然兼容，不用担心历史数据丢失。

sar 提供的是操作系统层面的性能数据，复盘时还需要结合应用日志、数据库慢查询日志、Web 服务器访问日志等一起分析。把 sar 时间轴上的异常点和应用日志中的错误时间点对齐，就能从现象追溯到根因。例如 sar 显示某时段网络重传率飙升，同时 Nginx 日志中出现大量 499 状态码，说明客户端因为超时主动断开连接，根因在网络而非应用代码。这种跨日志的关联分析是资深运维的必备技能，而 sar 的历史数据正是其中最关键的基础设施层证据。