简介：这一Linux系统性能监控经典工具包提供iostat、mpstat、vmstat等核心组件源码，面向系统管理员、运维人员及性能调优学习者，用于掌握CPU利用率、磁盘I/O、网络流量等关键指标采集与分析。资源共177个文件，以C语言源码、头文件、configure配置脚本为主，辅以多语言翻译文件（po）、文档和示例配置，整体约597KB，轻量精简，便于内网快速部署。已有470人学习下载，适合计划在自定义环境编译安装、定制监控功能的中级Linux用户。包内完整收录工具源码及辅助脚本，可借以深入了解sysstat的编译流程、日志数据格式，并参考iostat输出解读I/O瓶颈，或结合sadc、sadf构建周期性性能采集体系，直接服务于服务器容量规划与故障排查。
1. 老掉牙的 sysstat-11.5.6.tar.gz，为什么生产环境还在用它
先给结论：sysstat-11.5.6 这个版本的源码包，在 Linux 运维场景里就是"离线环境救命包"。能上网的发行版自带 sysstat 往往比这更新，但如果维护的是一批旧系统、内网隔离环境，或者生产系统明确锁定了软件基线，手里最可靠的往往就是这样一个 tar.gz。它能提供 sar、iostat、mpstat、pidstat 这一套完整性能数据采集工具，让你事后得以回看系统某个时间点到底发生过什么。
用这个版本的核心诉求很实际：不追求新功能，而是在目标机器上把性能监控跑起来。把二进制包化管理、依赖仓库这套标准化流程放一边，源码编译一个固定版本，配好定时任务，历史负载数据就能留下来。适合谁？维护老平台、内网机房或者做基准压测需要可控版本的人。下文给到的命令和参数，都是这类场景里最稳妥的通行做法。
2. 从源码包到可用二进制：编译安装的完整路径
sysstat 是老牌 C 程序，configure 几步就能过，依赖极少，这是它能在一堆旧机器上顺利编译的原因。我在三种情况下按下编译：一是目标机没有现成安装包；二是需要把监控工具打进自定义镜像；三是需要和基准数据严格对齐，避免不同小版本采样口径不一致带来误差。
2.1 查看包内容与依赖检查：动手前先花两分钟确认
拿到 tar.gz 不要直接解压就 configure，先确认包完整、文件列表齐全。常用做法是：
tar -tzf sysstat-11.5.6.tar.gz | head -30 tar -tzf sysstat-11.5.6.tar.gz | wc -l第一条列出档案内的文件开头部分，看是否有 configure、Makefile.in、sar 等源文件；第二条统计文件数量，如果数量异常少，可能被截断或下载不完整。-t是列出内容，-z按 gzip 解压读取，-f指定档案文件，三个参数组合是查阅 tar.gz 最标准的姿势。
随后检查编译链，执行gcc --version、make --version、ld --version三条命令逐一确认。sysstat 主要依赖 libc 和标准工具链，额外依赖很少。如果机器上连 gcc 都没有，就得先装基础工具链，离线环境往往从本地仓库装一批开发包，这一步是源码安装最常见的起步障碍。
依赖确认完再解压：
tar -xzf sysstat-11.5.6.tar.gz cd sysstat-11.5.6-x执行解压。解压后先看 README 和 INSTALL，这两个文件通常写了版本遗留问题和 configure 参数说明，对老版本来说，README 的信息比网上转述的博客更准确。我习惯顺手执行./configure --help看一眼当前版本真正支持的选项，因为不同 sysstat 版本的 configure 选项名有差异，不能照抄新版本教程。
2.2 configure 参数与 make：离线环境最常用的配置
11.5.6 的 configure 脚本是 autoconf 生成的，最典型的用法是：
./configure --prefix=/usr --enable-install-cron make -j4--prefix=/usr让二进制装进 /usr/bin，配套脚本装进 /usr/lib/sa/，这是发行版默认布局，后续直接用sar命令不用配 PATH。--enable-install-cron会在 make install 时尝试写入系统 crontab，自动把 sa1 和 sa2 配置好，适合内网标准机器。-j4让 make 并行编译提速；老平台 CPU 核数少，建议用-j2甚至不加，避免并行编译内存不足导致 make 中途退出。
如果你不希望系统 crontab 被自动改动，去掉--enable-install-cron即可。想自定义安装目录比如放到 /opt，就改--prefix=/opt/sysstat。另一个常见参数是--disable-nls，关掉多语言支持。有些老系统 locale 依赖不完整，编译 NLS 时会报缺头文件，直接关掉最省心。
configure 顺利退出后执行 make。常见报错是缺少 gettext 相关头文件，或 glibc 版本太老导致宏未定义。此时先看config.log末尾，能看到具体失败的编译命令和缺了哪个头文件。离线环境缺依赖时，最省事的方案是把同架构机器上的开发包拷贝过去，或者用本地源安装，不要硬改源码。
2.3 make install 与安装后验证：别急着跑测试就收工
编译完成后执行安装：
make install如果用了自定义 prefix，需确保安装路径已在 PATH 中。随后验证：
sar -V which sar iostat mpstat pidstat sadc sadfsar -V输出版本信息，直接确认主程序可用。which列出的每个命令都能找到路径，说明 make install 把可执行文件和脚本放到了正确位置。这里值得注意：11.5.6 会同时安装/usr/lib/sa/sa1、/usr/lib/sa/sa2、/usr/lib/sa/sadc，它们是后续定时采集的执行入口。多数人对sar熟，但 sa1/sa2 才是让数据落盘的关键，安装后要确认这几个文件存在。
再做一次快速功能测试：
sar -u 1 3每秒取一次 CPU 数据、连取三次退出。如果输出里有 CPU 使用率且数值非全 0，说明内核的 /proc 接口读取正常，sysstat 基本可用。若这里报Cannot open /proc/stat，多数是容器环境没挂载 /proc，或权限受限，不是安装本身的问题。
3. sar、iostat、mpstat、pidstat：用四个命令解决90%的定位场景
装好 sysstat 后，命令不是sar一个就够。实际排查顺序通常是：先用 sar 看整体负载和 CPU，再用 iostat 看磁盘有没有被打满，接着用 mpstat 看是否某个 CPU 核异常，最后 pidstat 定位具体进程。四个命令分工明确，哪一个都不能省。
3.1 sar：不带参数看的是历史，不是实时
很多刚接触 sysstat 的人有个误区：执行sar默认读的是当天累计数据，不是实时数据。sysstat 默认从 /var/log/sa/ 读取 saXX 文件。刚安装完系统还没有采集任务，裸执行sar会提示没有数据文件，这不算是故障。实时查看要显式加采样间隔：
sar -u 2 5 sar -r 2 5 sar -q 2 5 sar -n DEV 2 5参数含义：-u查 CPU 使用率，包括 user、system、iowait、idle 等列；-r查内存与交换分区；-q查负载均值与可运行线程数；-n DEV查网络设备吞吐。后面的2 5表示每 2 秒采样一次一共 5 次。我习惯把它看成"即时体检"：CPU 和内存看实时状态，iowait 持续超过 30%，大概率磁盘是瓶颈。
查看历史数据要指定文件：
sar -u -f /var/log/sa/sa$(date +%d) sar -r -f /var/log/sa/sa$(date +%d) -s 08:00:00 -e 10:00:00-f指定数据文件，-s和-e限定起止时间。这条命令在事后复盘时最常用。例如上午业务反馈变慢，下午拉取当天早高峰的 CPU 和内存，一条命令完成。注意-f不能和实时采样参数混用，两者互斥。
3.2 iostat：把瓶颈锁定到具体磁盘
iostat 主要看设备级 IO 指标。它不是看整体吞吐，而是看每个磁盘的利用率、每秒读写次数、平均等待时间。一个常见定位流程是：
iostat -x 2 3 iostat -d -x /dev/sda 1第二条指定只看 /dev/sda。关键列是%util（设备忙占比）、await（平均 IO 等待毫秒数）、svctm。如果%util接近 100% 且await很高，说明磁盘确实繁忙；如果%util不高但await高，要怀疑硬件故障或调度器队列问题，例如磁盘链路老化或硬盘快挂了。
-x是扩展统计，-d只显示设备而不显示分区，减少噪音。加-k或-m可以分别用 KB/s 或 MB/s 显示吞吐。线上定位时，我一般先不加-d看全部分区，再按 top 几个磁盘继续追。iostat 的数据来源是 /proc/diskstats，某些虚拟化磁盘在宿主机有缓存时，客户机看到的 %util 会被稀释，要结合吞吐绝对值判断，不能只看百分比。
3.3 mpstat 与 pidstat：从多核 CPU 拆到单进程
mpstat 与 sar -u 的区别在于能按 CPU 核拆分：
mpstat -P ALL 2 3 mpstat -P 0 2 2-P ALL显示所有核的使用率，快速判断负载是否均衡。如果 8 个核中第 3 个核 100% 而其余都是 5%，说明这个负载本质串行，不是机器配置不够。-P 0只看第 0 号核。CPU 核 ID 从 0 开始计数，不要拿 lscpu 里的编号直接套。
pidstat 则是最后一步：
pidstat -u 1 3 pidstat -d 1 3 pidstat -r 1 3-u按进程显示 CPU 占用，-d显示进程读写 IO，-r显示内存占用。三条命令同时执行可以把一个进程的 CPU、IO、内存行为拼成全景，比 top 的瞬时快照稳定。定位具体进程时加-p PID；需要看线程级别时加-t。11.5.6 的 pidstat 功能已经很完整，日常做进程级定位这一套足够。
4. 数据自动落盘：sa1、sa2 与 crontab 采集链路的完整配置
sar 的历史数据不是天然就有的。它由 sadc 周期性写入二进制数据文件，再由 sa1/sa2 配合 crontab 调度。如果不配定时任务，sar 永远只能看实时数据，事后复盘就没有依据。装完 sysstat 后最核心的动作，是把采集链路配起来。
4.1 理解数据流向：sadc 写数据、sa1 调用、sa2 出报告
sysstat 的采集链路很直接。sadc 是数据收集器，每次执行都把当前系统指标追加写入/var/log/sa/saDD文件（DD 是当天日期）。sa1 是 sadc 的封装脚本，面向 crontab 调用。sa2 是当日汇总脚本，在一天结束时把 saDD 生成成文本报告。三者分工就是：sa1 负责周期性采集，sa2 负责汇总出报表。
手动验证采集链路可执行：
/usr/lib/sa/sa1 1 1 ls -l /var/log/sa/如果采集正常，/var/log/sa/ 下会生成 saDD 文件。没有生成时，优先检查目录属主和写权限，确认当前用户能否写。注意不同发行版把 sa1 放在 /usr/lib/sa 还是 /usr/local/lib/sa，取决于 make install 的 prefix。核对数据文件能否读取：
sadf -d /var/log/sa/sa$(date +%d) -- -u | head -5sadf是数据格式转换工具，-d让输出成为分号分隔的表格。能读到 CPU 指标说明采集与存储都正常。
4.2 修改 crontab：把默认 10 分钟改成更细粒度
sysstat 默认通过--enable-install-cron写入系统 crontab（通常在 /etc/cron.d/sysstat），默认每 10 分钟采集一次。如果你要更细的粒度，直接编辑用户 crontab：
crontab -e写入以下两行：
*/2 * * * * /usr/lib/sa/sa1 1 1 53 23 * * * /usr/lib/sa/sa2 -A第一行表示每 2 分钟执行一次/usr/lib/sa/sa1 1 1，参数含义是采样间隔 1 秒、采集 1 次。在调度语义里，这代表"每次被 cron 唤醒时快速取一个点"，下一个 2 分钟后取第二个点，实际组成约每 2 分钟一个数据点。粒度越细数据文件增长越快，生产机器建议保持 5 到 10 分钟。第二行每天 23:53 运行sa2 -A，-A代表生成全量日报。对高磁盘负载机器，去掉-A只生成平均和峰值报告，能减少 IO 开销。
改完重启 cron 服务：
systemctl restart crond少数发行版服务名是 cron 而非 crond，命令稍有差异。配置完成后，下一次整 2 分钟时数据开始落盘。我习惯改完等 3 分钟，执行ls -l /var/log/sa/，看到 saDD 文件 mtime 在变化即确认调度生效；若 mtime 不变且文件大小完全一样，多半是 cron 没重启或 sa1 路径写错。
4.3 用 sadf 导出 CSV：给监控平台和数据复盘供数
二进制 saDD 文件人读起来不方便，交给监控平台更不行。sadf 是官方转换工具，能输出 CSV 或 XML。日常最有用的是：
sadf -d /var/log/sa/sa$(date +%d) -- -u > /tmp/cpu_$(date +%d).csv sadf -d /var/log/sa/sa$(date +%d) -- -r > /tmp/mem_$(date +%d).csv sadf -d /var/log/sa/sa$(date +%d) -- -n DEV > /tmp/net_$(date +%d).csv--后面的参数与 sar 的参数一致，表示这条命令导出的是"用 sar -u 这种视角解析的数据"。导出的 CSV 带表头，字段包含时间戳、主机名和指标列，直接用 Excel 打开即可画趋势。要把 CSV 接入监控平台，我通常把这几条写成每日任务脚本，输出到指定目录后由采集组件读取。sadf 的-T选项可输出可读时间，老版本不一定支持，用前先sadf -?看帮助比较稳妥。
5. sysstat 编译与使用中的 4 个典型坑：排查路径按这个走
这章写给踩坑的人。11.5.6 是相对老的版本，在新系统上编译或运行出现的某些现象并非偶然，按下面的路径排查可以减少大量盲试时间。
5.1 现象：configure 通过但 make 时报cannot find -lintl
某 A 同学在精简系统上编译，configure 顺利退出，make 阶段链接 NLS 时报缺 libintl。原因是 gettext 的库与头文件没装全，configure 只在检查头文件时通过，链接时的实际依赖没覆盖到。
解决方式：能联网就直接装开发包；离线环境最常见做法是找同大版本系统的二进制包，解包后拷到 /usr 下。不依赖 NLS 时，直接在 configure 阶段加--disable-nls绕开，sysstat 核心功能与语言文件无关，做监控完全不需要国际化支持。这是我优先推荐的方式，不是所有功能都值得为它补依赖。
5.2 现象：sar 输出系统时间与业务日志时间对不上
曾有一次复盘，CPU 尖峰在 sa 文件里显示为 10:12，业务日志显示故障从 10:18 开始。排查后发现问题不在 sysstat，而是系统时区配置错误。sar 采集时间用的是内核时间，和业务日志侧时间基线不一致，数据本身没错，错在了系统时间基线不统一。
解决方式：先date看系统时间，用timedatectl list-timezones确认时区，不一致时先校正系统时钟再重新采集。另一个坑是环境变量：LC_ALL=C强制 sar 输出英文，LC_ALL=zh_CN.UTF-8会输出本地化内容，脚本解析时混用会翻车。凡是用 sar 输出做自动解析的脚本，开头统一export LC_ALL=C，让字段名稳定，不要指望本地化输出做正则匹配。
5.3 现象：老版本 sysstat 在新内核上数据全 0 或数值为负
某新版本内核的机器上 sar -u 显示 idle 为负值，iostat %util 恒为 0。这个现象在老版本 sysstat 上偶发，原因是 /proc/stat 和 /proc/diskstats 的输出列数随内核版本变化，老版本按旧列号解析，字段错位后出现异常值。这是典型的版本兼容陷阱，不是服务器故障。
解决方式：优先升级 sysstat 到与内核匹配的版本，或在编译时确认 configure 日志中内核相关宏已正确定义。如果生产环境锁定了 11.5.6，先执行cat /proc/stat手工数一下列，若字段数与老版本不一致，就不要在这个内核上继续用旧版采集，否则后面所有复盘数据都不可信。所谓"玄学数据"很多时候只是列错位。
5.4 现象：/var/log/sa 目录占满磁盘
某台机器跑了一年，sa 目录膨胀到几个 GB 触发磁盘告警。原因是 sa1 采集频率过高，同时 saDD 二进制文件不会自动清理。老版本 sysstat 不自带日志轮转策略，磁盘塞满后其他服务开始报错，这时再处理代价就大了。
解决方式：在 crontab 中额外加一条清理任务，保留最近 30 天数据即可：
30 2 * * * find /var/log/sa -name 'sa*' -type f -mtime +30 -delete每天凌晨 2:30 把 30 天前的数据删掉。另一个方向是调低采集频率，把*/2 * * * *改成*/10 * * * *，数据量可降一个数量级。要保留更久，建议用 sadf 每天导出一次汇总 CSV 归档，二进制原始文件不长期留，既能复盘关键指标又不占盘。
6. 用 sadf 做一周数据对比：把七天浓缩成一行结论
最后落到一个具体技巧：用 sadf 把本周每天的数据抽成"峰值数值、峰值时间点"两个指标，输出成简洁表格。这在写周报、做容量评估、判断是否扩容前非常实用：
for d in $(seq 1 7); do sadf -d /var/log/sa/sa$d -- -u \ | awk -F';' 'NR>1 {if($4>max){max=$4;t=$2}} END {printf "day %s: max_cpu=%s at %s\n", "'$d'", max, t}' done这段脚本逐个读本周 7 天的 sa 文件，取每天 CPU 用户态的峰值和对应时间点。sadf -d输出分号分隔字段，awk 以分号分隔取值，第 2 列是时间戳，第 4 列是用户态 CPU 占比。这里要特别提醒：不同 sysstat 版本及不同参数组合下，字段列顺序有差异，首次使用先手动执行一次sadf -d /var/log/sa/saDD -- -u | head -3，确认时间戳和 CPU 列的具体位置再套用 awk。NR>1跳过表头，$4>max记录最大值，END块输出当天结论。
把同样的思路扩展到内存，只需换成-r并修改列号，就能得到一周七天每天的内存峰值。我更常用的做法是把输出重定向到一个文本文件，再配合制表符导入在线表格，一周的负载趋势用几行文本就讲完。这个技巧的意义在减少人盯屏幕的时间，数据能说话就不必开着 sar 一页页翻。
这也是我踩了不少坑后养成的习惯：新机器装完 sysstat，先确认版本、再核对时区、最后验证采集链路，半小时内让历史数据开始落盘。排查时宁可多打几条sadf验证列位置，也不要拿老版本硬套新内核的数据结构。按这套流程操作，sysstat-11.5.6 应当能一次装通，数据采上、坑都避开，少在深夜踩无谓的雷。希望帮到你。
本文还有配套的精品资源，点击获取
