简介sysstat-11.5.6.tar.gz 是 Linux 系统性能监控工具集的源码压缩包面向系统管理员、运维工程师及需要排查性能瓶颈的开发者。它集成 iostat、mpstat、vmstat、sadc、sadf、sa1/sa2 等核心组件可采集并分析 CPU 利用率、磁盘 I/O、内存与交换空间、网络流量等关键指标帮助定位 I/O 瓶颈、评估多处理器负载均衡、持续记录系统运行状态。压缩包共 177 个文件约 597KB以 25 个 c 源文件、19 个 h 头文件、35 个 po 本地化文件、25 个 in 模板及 configure、install、spec 等构建脚本为主另含 man 手册、示例配置与文档便于在自有 Linux 环境编译安装。已有 470 人学习下载。通过阅读源码与配套文档读者可理解性能数据采集机制、报表生成流程与定时任务配置方式为系统调优和故障排查提供可复用的工具基础。1. sysstat-11.5.6.tar.gz 到底是什么从源码包到性能数据流水线拿到sysstat-11.5.6.tar.gz这个文件时很多人第一反应是「这不就是个压缩包吗」然后tar -xzf解压、./configure make make install三连装完sar能跑就完事了。但真正在生产环境里靠它定位过 CPU 飙高、磁盘 IO 打满、内存泄漏的人都知道这个 tar.gz 背后是一整套 Linux 性能数据采集、持久化和回溯分析的流水线。sysstat 这个工具集包含sar、iostat、mpstat、pidstat、sadf等十几个命令其中sar是唯一一个能把历史性能数据落盘、事后回看的工具。你半夜两点被报警叫醒服务已经恢复了这时候top什么都看不到能救你的只有sar昨天留下的二进制数据文件。这篇笔记面向的是需要在裸机或容器里从源码编译部署 sysstat、并且要把它接进监控体系的运维和 SRE我会把编译参数、采集配置、数据文件结构、排错路径全部拆开讲清楚让你拿到这个 tar.gz 之后不只是「装上」而是真正把它变成一套可回溯的性能数据底座。2. 从 tar.gz 到可用命令编译参数与安装路径怎么定2.1 为什么不用包管理器而要从源码编译大部分发行版的仓库里都有 sysstat 的预编译包yum install sysstat或apt install sysstat一条命令就完事。但实际工作中从源码编译sysstat-11.5.6.tar.gz有几个绕不开的理由。第一是版本锁定发行版仓库里的 sysstat 版本往往偏旧比如某些 LTS 系统还停在 10.x而 11.5.6 在sar的数据采集精度、pidstat的线程级统计、以及对新内核 cgroup v2 的兼容性上都有改进。第二是编译选项控制预编译包通常开启了默认的采集间隔和日志轮转策略你没法在编译期调整默认行为。第三是容器镜像瘦身场景你需要把 sysstat 静态编译或者装到一个极简的基础镜像里包管理器带来的依赖链太重。我一般会在编译前先确认三件事内核版本、glibc 版本、以及目标机器上是否已经有旧版 sysstat 在跑。旧版没清干净会导致sar命令路径混乱which sar指向的可能是/usr/bin/sar而不是你刚编的/usr/local/bin/sar这个坑后面避坑章节会细说。2.2 解压与 configure 的关键参数先解压然后进目录看INSTALL文件和configure --help不要上来就./configure。sysstat 的 configure 脚本有几个参数直接决定了你后面采集行为对不对。# 解压到工作目录 tar -xzf sysstat-11.5.6.tar.gz cd sysstat-11.5.6 # 查看可用的 configure 选项重点关注 prefix 和 sa_dir ./configure --help | grep -E prefix|sa_dir|collect|history看完帮助信息之后按你的实际需求配置。下面这套参数是我在物理机和虚拟机上通用的配置# 配置编译选项 ./configure \ --prefix/usr/local \ --sysconfdir/etc/sysstat \ --sa-dir/var/log/sa \ --enable-install-cron \ --disable-man-group # 编译-j 后面跟 CPU 核心数加速 make -j$(nproc) # 安装 sudo make install--prefix/usr/local把二进制装到/usr/local/bin避免和系统自带的/usr/bin/sar冲突。--sysconfdir/etc/sysstat指定配置文件目录sysstat 的主配置文件是sysstat这个文件里面控制采集开关、间隔、历史保留天数。--sa-dir/var/log/sa是二进制数据文件的存放目录sa是 system activity 的缩写这个目录下的文件按天命名比如sa15表示当月 15 号的数据。--enable-install-cron会自动安装 cron 任务这是 sysstat 数据采集的调度入口非常关键。--disable-man-group是跳过 man 手册的组权限设置在容器里编译时经常因为缺少 man 用户组而报错加上这个参数可以绕过。2.3 安装后的目录结构与文件职责编译安装完成后你需要清楚每个文件在哪里、干什么用。下面这张表是我整理的核心文件清单路径类型作用/usr/local/bin/sar二进制主力命令采集和查看性能数据/usr/local/bin/iostat二进制磁盘 IO 统计/usr/local/bin/pidstat二进制进程级 CPU/内存 I/O 统计/usr/local/bin/sadf二进制把二进制数据文件转成 CSV/XML/JSON/etc/sysstat/sysstat配置文件控制采集开关、间隔、保留天数/var/log/sa/saDD数据文件每天一个二进制文件DD 是日期/var/log/sa/sarDD数据文件sadf 生成的文本格式日报/etc/cron.d/sysstatcron 任务定时调用 sa1 和 sa2 采集数据sa1和sa2是两个脚本sa1负责采集二进制数据写入saDDsa2负责把当天的数据转成文本日报sarDD。cron 任务里通常配两条一条每 10 分钟跑sa1一条每天 23:53 跑sa2。这个调度逻辑是 sysstat 数据能持续留存的核心如果 cron 没装好sar只能看实时数据历史数据一条都没有。提示编译完成后先跑sar -V确认版本号是 11.5.6再跑which sar确认路径是/usr/local/bin/sar。两个都对才算装干净了。3. 让数据自动落盘cron 调度、采集间隔与保留策略3.1 sysstat 配置文件里真正要改的几个参数/etc/sysstat/sysstat这个文件里参数不少但真正影响采集行为的就几个。我见过太多人装完之后这个文件看都没看过结果默认配置采集间隔太长、保留天数太短出了故障回看数据发现粒度不够或者数据已经被删了。# /etc/sysstat/sysstat 关键配置项 # 是否启用 sar 数据采集默认 true ENABLEDtrue # 采集间隔秒默认 10 分钟 # 生产环境建议 60~300 秒太短磁盘写入压力大太长故障时看不到细节 SA1_OPTIONS-S DISK -S INT -S IP -S EQQ -S XDISK -S POWER -S SNMP # 历史数据保留天数默认 7 天 # 建议至少 30 天有合规要求的可以设 90 天 HISTORY30 # 压缩旧数据文件节省磁盘 COMPRESSAFTER10 # 是否生成日报 ZIPtrueSA1_OPTIONS里的-S参数控制采集哪些子系统。DISK是磁盘统计INT是中断统计IP是网络统计EQQ是队列统计POWER是电源管理SNMP是 SNMP 计数器。不是所有子系统你都需要比如纯计算节点不需要IP但数据库节点DISK和EQQ必开。每多开一个子系统采集时多读一批/proc和/sys文件对系统有轻微开销但通常可以忽略。HISTORY30这个值要结合你的磁盘空间算。一个saDD文件在默认采集粒度下大约 1~5 MB30 天就是 30~150 MB加上压缩后更小。但如果你的采集间隔是 10 秒文件会大 6 倍这时候要么加大 HISTORY 对应的磁盘配额要么放宽采集间隔。3.2 cron 任务的正确配法sysstat 安装时如果带了--enable-install-cron会在/etc/cron.d/sysstat生成调度文件。但不同发行版的 cron 目录位置不一样有的在/etc/cron.d/有的在/var/spool/cron/。我一般会手动确认一遍。# 查看 sysstat 的 cron 任务 cat /etc/cron.d/sysstat # 典型内容如下 # 每 10 分钟采集一次二进制数据 */10 * * * * root /usr/local/lib/sa/sa1 1 1 # 每天 23:53 生成日报 53 23 * * * root /usr/local/lib/sa/sa2 -Asa1 1 1这两个参数的含义是采集间隔 1 秒采集 1 次。等等这里有个容易搞混的地方。sa1的完整参数是sa1 [interval [count]]但 cron 里写的1 1并不是说只采集 1 秒。实际上sa1在 cron 模式下会读取/etc/sysstat/sysstat里的配置1 1是占位参数表示用配置文件里的间隔。真正决定采集频率的是 cron 表达式*/10也就是每 10 分钟触发一次sa1每次sa1采集一个时间点的数据。sa2 -A里的-A表示生成所有子系统的日报。日报是文本格式方便直接cat或者grep但二进制文件saDD才是sar命令直接读取的源数据。注意如果你的系统用的是 systemd timer 而不是 cron需要手动创建 timer 单元文件。systemctl list-timers | grep sysstat可以确认是否已有 timer 在跑。3.3 验证数据是否真的在采集配置完之后不要等第二天再看当场验证。手动触发一次采集然后立刻用sar读。# 手动触发一次采集 sudo /usr/local/lib/sa/sa1 1 1 # 查看今天的数据文件是否生成 ls -lh /var/log/sa/sa$(date %d) # 用 sar 读取今天的 CPU 数据 sar -u -f /var/log/sa/sa$(date %d) # 查看磁盘 IO 历史 sar -d -f /var/log/sa/sa$(date %d) # 查看内存历史 sar -r -f /var/log/sa/sa$(date %d)如果sar -u能输出表格说明数据采集和读取链路是通的。如果报错Cannot open /var/log/sa/sa15: No such file or directory说明sa1没执行成功回去检查 cron 权限和sa1脚本路径。如果sar输出了数据但时间戳不对检查系统时区和sa1执行时的环境变量。4. 读懂 saDD 二进制文件sar 常用参数与数据回溯实战4.1 sar 命令的参数组合逻辑sar的参数分三类控制读实时还是读历史、控制看哪个子系统、控制输出格式。这三类参数可以自由组合但顺序有讲究。基本语法是sar [选项] [间隔] [次数]。# 实时采集每 2 秒采一次共采 5 次 sar -u 2 5 # 读历史文件读 15 号的 CPU 数据 sar -u -f /var/log/sa/sa15 # 读历史文件并指定时间范围只看 14:00 到 16:00 sar -u -f /var/log/sa/sa15 -s 14:00:00 -e 16:00:00 # 看磁盘 IO每 5 秒一次共 3 次 sar -d 5 3 # 看网络统计读历史文件 sar -n DEV -f /var/log/sa/sa15 # 看内存和交换分区 sar -r -S -f /var/log/sa/sa15-s和-e是回溯分析时最常用的两个参数。故障发生在下午三点你不需要把一整天的数据都打出来用-s 14:30:00 -e 15:30:00把范围缩到一小时输出量小很多关键指标也更容易看。-n参数后面跟的子选项决定看哪类网络数据。DEV是网卡级别的收发字节和包数EDEV是错误统计NFS是 NFS 客户端统计SOCK是 socket 统计。排查网络问题时DEV和EDEV一起看先看流量再看错误。4.2 从 sar 输出里定位性能问题的三个套路CPU 飙高的回溯用sar -u -f saDD -s 故障开始时间 -e 故障结束时间重点看%user、%system、%iowait、%steal四列。%user高说明应用层在烧 CPU%system高说明内核态开销大通常是系统调用频繁或上下文切换多%iowait高说明 CPU 在等磁盘%steal高说明虚拟机被宿主机抢了 CPU。这四个指标的组合能快速缩小排查方向。磁盘 IO 打满的回溯用sar -d -f saDD -s ... -e ...重点看tps、rd_sec/s、wr_sec/s、await、%util。%util接近 100% 说明磁盘饱和await突然升高说明 IO 延迟变大。如果tps不高但await很高通常是单次 IO 太大或者磁盘本身有问题。如果tps很高但await正常说明是大量小 IO可能是应用没做批量写。内存泄漏的回溯用sar -r -f saDD重点看kbmemfree、kbmemused、%memused、kbcached。如果kbmemfree持续下降、kbcached没有相应增长说明有进程在泄漏内存。这时候配合pidstat -r -f或者sar -r的进程级数据需要pidstat单独采集定位到具体进程。4.3 用 sadf 把二进制数据转成可分析的格式sar的输出是给人看的但如果你想把数据接进监控系统或者做二次分析需要sadf把saDD转成结构化格式。# 转成 CSV方便导入 Excel 或数据库 sadf -d /var/log/sa/sa15 -- -u cpu_15.csv # 转成 JSON方便程序解析 sadf -j /var/log/sa/sa15 -- -u -s 14:00:00 -e 16:00:00 cpu_15.json # 转成 XML sadf -x /var/log/sa/sa15 -- -d disk_15.xml # 一次导出所有子系统到 CSV sadf -d /var/log/sa/sa15 all_15.csvsadf的--后面的参数会透传给sar所以sadf -d sa15 -- -u -s 14:00:00等价于先sar -u -s 14:00:00再转 CSV。-d是 CSV 格式-j是 JSON-x是 XML。CSV 适合人看和导入表格JSON 适合程序消费。提示sadf导出的 CSV 第一行是表头字段名和sar输出一致。导入数据库时注意时间戳字段的格式是YYYY-MM-DD HH:MM:SS本地时区。5. 避坑与排查编译、采集、回溯三个阶段的翻车记录5.1 编译时报 undefined reference toget_mempolicy现象make到最后链接阶段报错提示undefined reference to get_mempolicy或类似 NUMA 相关函数找不到。原因sysstat 的pidstat和sar在采集内存数据时会调用 NUMA 相关系统调用需要链接libnuma。但 configure 阶段没有检测到libnuma开发库或者检测到了但链接参数没加上。解决先装libnuma-develRPM 系或libnuma-devDebian 系然后重新./configure。如果已经装了还是报错在 configure 时显式指定LDFLAGS-lnuma。容器里编译的话确认基础镜像里有numactl包。5.2 cron 跑了但 saDD 文件不生成现象/etc/cron.d/sysstat文件存在cron 服务也在跑但/var/log/sa/目录下就是没有当天的saDD文件。原因最常见的是sa1脚本路径不对。编译安装时sa1被装到了/usr/local/lib/sa/sa1但 cron 文件里写的可能是/usr/lib/sa/sa1系统自带版本的路径。另一个原因是/var/log/sa目录权限不对cron 以 root 跑但目录属主是别的用户。解决which sa1确认实际路径然后改/etc/cron.d/sysstat里的路径。权限问题用chown root:root /var/log/sa chmod 755 /var/log/sa修复。改完等一个采集周期或者手动sudo -u root /usr/local/lib/sa/sa1 1 1测试。5.3 sar 读历史文件报「Invalid system activity file」现象sar -u -f /var/log/sa/sa15报错Invalid system activity file: /var/log/sa/sa15。原因这个报错通常有三种可能。一是文件确实损坏了比如采集过程中系统断电导致写入中断。二是文件是旧版本 sysstat 生成的新版本sar读不了旧格式。三是文件被sadf或其他工具修改过头部魔数不对。解决先用file /var/log/sa/sa15看文件类型正常应该是data。如果是ASCII text说明这个文件被误写成文本了不是二进制数据文件。版本不兼容的话只能用对应版本的sar读或者用sadf先转成文本再用新版工具分析。损坏的文件基本救不回来检查磁盘和文件系统日志找原因。5.4 采集间隔设太短导致磁盘 IO 升高现象把sa1的采集间隔从 10 分钟改成 10 秒之后系统%iowait明显升高sar -d看到saDD文件所在磁盘的写入量大幅增加。原因每次sa1执行都会读取/proc和/sys下大量文件然后写入saDD。10 秒一次意味着每分钟 6 次采集每次采集涉及几十个文件读取和一次磁盘写入。在 IO 本来就紧张的系统上这个开销会叠加。解决采集间隔不要低于 60 秒。如果确实需要秒级精度用sar实时采集而不是落盘或者把saDD目录放到 tmpfs 上但重启会丢数据。折中方案是平时 5 分钟采集一次需要精细排查时临时手动sar -u 1 60采一分钟。5.5 容器里 sar 看不到宿主机数据现象在容器里装了 sysstatsar能跑但看到的数据和宿主机top对不上CPU 核数、内存总量都是容器的限制值而不是宿主机的。原因sar读的是/proc/stat、/proc/meminfo这些文件容器里的/proc默认是隔离的看到的是容器命名空间内的视图。除非容器以--privileged或--pidhost启动否则sar拿不到宿主机全局数据。解决如果目标是监控宿主机sysstat 应该装在宿主机上而不是容器里。如果必须在容器里采集用--pidhost --nethost启动容器并且把宿主机的/proc和/sys挂载进去。但这样容器就和宿主机共享命名空间了安全边界要评估清楚。6. 把 sysstat 接进监控体系sadf 脚本做自动化日报6.1 用 sadf 导出 JSON 并做阈值告警sysstat 本身没有告警功能但sadf导出的 JSON 可以接进任何监控系统。我一般会写一个每天跑一次的脚本把前一天的saDD转成 JSON提取关键指标超过阈值就发通知。#!/usr/bin/env python3 # sysstat_daily_check.py # 读取前一天的 saDD 文件检查 CPU/内存/磁盘关键指标 import json import subprocess import sys from datetime import datetime, timedelta # 计算前一天的日期 yesterday (datetime.now() - timedelta(days1)).strftime(%d) sa_file f/var/log/sa/sa{yesterday} # 用 sadf 导出 JSON只取 CPU 和内存 try: result subprocess.run( [sadf, -j, sa_file, --, -u, -r], capture_outputTrue, textTrue, timeout30 ) data json.loads(result.stdout) except Exception as e: print(f读取 {sa_file} 失败: {e}) sys.exit(1) # 提取 CPU 使用率和内存使用率 alerts [] for host in data.get(sysstat, {}).get(hosts, []): for stat in host.get(statistics, []): # CPU 检查 if cpu-load in stat: for cpu in stat[cpu-load]: user float(cpu.get(user, 0)) system float(cpu.get(system, 0)) iowait float(cpu.get(iowait, 0)) total user system iowait if total 85: alerts.append(fCPU 使用率 {total:.1f}% 超过阈值) # 内存检查 if memory in stat: mem stat[memory] used_pct float(mem.get(percent, 0)) if used_pct 90: alerts.append(f内存使用率 {used_pct:.1f}% 超过阈值) if alerts: print(发现异常:) for a in alerts: print(f - {a}) sys.exit(2) else: print(所有指标正常) sys.exit(0)这个脚本的逻辑是用sadf -j把saDD转成 JSON遍历statistics数组里的每个时间点提取 CPU 的user、system、iowait和内存的percent字段超过阈值就收集告警。sadf的 JSON 结构是嵌套的sysstat.hosts[].statistics[]这一层对应每个采集时间点里面的cpu-load和memory是子系统数据。脚本退出码 0 表示正常2 表示有告警可以接进 cron 或者 CI 流水线。6.2 用 sar 数据做容量趋势分析单天的数据看故障多天的数据看趋势。把最近 30 天的saDD文件用sadf批量导出按天聚合 CPU 和内存的峰值画成趋势图能提前发现容量瓶颈。# 批量导出最近 30 天的 CPU 峰值 for i in $(seq 1 30); do day$(date -d -$i days %d) sa_file/var/log/sa/sa${day} if [ -f $sa_file ]; then # 导出当天 CPU 数据取 usersystem 的最大值 sadf -d $sa_file -- -u | \ awk -F; NR1 {print $1, $4$5} | \ sort -k2 -rn | head -1 | \ awk -v d$day {print d, $2} fi done | sort -k1 -n这段脚本遍历最近 30 天的saDD文件用sadf -d导出 CSVawk提取时间戳和usersystem列排序取最大值最后按日期输出。输出结果可以直接喂给绘图工具看 CPU 峰值是不是在逐天上升。内存趋势同理把-u换成-r取%memused列。6.3 一个我踩过的坑sadf 的时区和时间戳sadf导出的时间戳默认是本地时区但如果你的服务器时区是 UTC 而你看数据的时候按北京时间理解就会差 8 小时。我有一次排查故障sar显示 CPU 飙高发生在 06:00我以为是早上六点结果实际是北京时间 14:00白白多查了两个小时。后来我养成了一个习惯所有sadf导出的数据第一件事是date确认服务器时区然后在脚本里统一转成 UTC 或者显式标注时区。sadf本身没有时区转换参数时区处理要在导出后的脚本里做。另一个习惯是每次编译安装完 sysstat我会先跑一周的采集然后手动做一次完整的「导出 → 分析 → 告警」流程确认整条链路通了再交给监控系统。sysstat 这套工具不复杂但细节多编译参数、cron 路径、时区、文件权限任何一个环节出问题都会导致关键时刻没有数据可查。希望帮到你。本文还有配套的精品资源点击获取