简介这是一份面向 Linux 运维人员与系统管理员的 sysstat 11.5.6 源码安装包包含 CPU 利用率、磁盘 I/O、网络流量等性能监控所需的完整工具链适用于服务器性能调优、故障排查与日常运行状态巡检等场景。压缩包共 177 个文件大小约 597KB以 c、h 源文件in 配置模板po 多语言翻译文件1 手册页等类型为主并附带 configure 配置脚本、sadc 数据收集器相关选项及安装说明文件便于在本地编译部署。资源中还包括 isag、sargraph 等辅助图形化工具与 cron 定时采集配置示例帮助用户实现自动化监控和报表生成。发布者为 ssxueyi已有 470 人浏览学习适合具有一定 Linux 基础、希望深入理解系统性能指标并动手编译部署监控工具的中高级学习者。通过编译安装这一版本读者可以完整了解 sysstat 从源码构建到日常使用的过程并借助 iostat、mpstat、vmstat、sadf 等核心命令定位 I/O 瓶颈、评估多核负载并分析内存与交换空间状况进而提升服务器稳定性与运维效率。1. 拿到 sysstat-11.5.6.tar.gz我为什么不急着解压sysstat-11.5.6.tar.gz 在 Linux 服务器上是个很常见的东西它是 sysstat 这个性能监控工具集的 11.5.6 版本源码包解开之后里面有 sar、mpstat、iostat、pidstat 这些我每天都要打交道的命令。拿到这样一个源码包我的习惯不是第一时间解压而是先把几个问题摆到桌面上装在哪个前缀路径、谁来定时调用 sadc、历史日志留几天、会不会和发行版自带的 sysstat 打架。这些问题没想清楚装完就会得到一套能和系统共存、却没法让你快速定位瓶颈的工具——只多了一个黑匣子而不是多一双眼睛。这篇我按自己惯用的流程把从解压到落地的完整路径走一遍。2. sysstat 的组成结构与版本选型为什么要留 11.5.6sysstat 不是一个大而全的二进制它是一条完整的链路。采集端是 sadc负责把内核里的计数器读出来写进二进制文件sa1 是一个外层壳按固定周期调用 sadcsa2 则负责在一天结束时把多个数据点合并归档顺便触发统计汇总。读数据这一侧是 sar 和 sadf而 mpstat、iostat 这类命令是直接读内核统计、不走历史文件的。理解这条链路后面所有配置才有依据。2.1 三条命令先看懂环境编译前自检我一般会在解压前先做一轮环境自检不是走形式是为了少返工。sysstat 的编译依赖非常轻但缺了某一样就是会卡在 configure 阶段给你看脸色。# 检查编译链是否完整 gcc --version make --version # 检查是否有 zlib 开发库影响 sa 文件能否压缩 ldconfig -p | grep zlib || echo zlib 未安装 # 检查 cron 服务是否在跑11.5.6 最常见的调度方式还是 cron systemctl is-active crond 2/dev/null || service crond statusgcc 和 make 是硬依赖缺了直接用发行版包管理器装上即可。zlib 不是必须但缺了之后 configure 会关闭文件压缩支持sa 日志文件会偏大对磁盘紧张的小机器来说是个隐性成本。第三条检查的是调度器如果系统里 cron 没在跑后面就算把脚本放进 /etc/cron.d/ 也不会执行这是很多人在最后一步才发现的坑。自检完之后还有一步更重要看看当前系统里是否已经装过 sysstat。which sar sar -V很多服务器上其实已经带了发行版预编译的 sysstat只是版本偏低。如果不看当前路径就急着 make install最后敲 sar 时大概率命中的还是旧版本。这个问题不解决后面所有验证都是错的这也是这个标题下翻车率最高的一个环节。2.2 为什么这个版本值得留一份源码包有人会问直接发行版包管理器装一个 sysstat 不就行了为什么非要留 11.5.6 的源码包我的回答是可预期性。下面这张对比表说的是 11.5.6 这一代和后续新版之间最明显的差异也是我在生产上选型时实际会权衡的点。对比维度11.5.6 常见行为新版常见变化日志文件命名/var/log/sa/saDD部分新版改用 saYYYYMMDD默认压缩基本不压缩新版逐步默认开启压缩调度方式依赖 cron行为简单更多向 systemd timer 迁移iostat 输出还有 svctm 列后续大版本已移除 svctm内核特性覆盖覆盖基础统计项覆盖压力失忆等新统计如果你的诉求是 CPU、内存、磁盘、进程这些基础维度11.5.6 完全够用而且它的文档和行为在网络上沉淀时间最长遇到问题能搜到大量真实案例。我留源码包还有一个私心同一台服务器上用同一版本采集、同一版本读取数据格式不会有版本错位这种玄学问题。当你想排查的是一个持续了三天、只在深夜出现的负载尖峰时最怕的就是历史文件打不开或读出来是一堆格式错乱的值。固定版本等于把这类问题挡在门外。2.3 从源码装的控制权收益从包管理器安装省事但它会跟随发行版升级今天还是这个版本某次系统更新后可能就换成了新版行为也随之变化。监控工具最怕的不是功能少而是行为突然变。源码安装的核心收益是控制权装在哪个路径自己定配置文件自己写调度方式自己选后续要不要升级也自己说了算。对于需要长期运维的服务器这个确定性比省那几分钟宝贵得多。确认环境没问题、也看清了当前的版本冲突之后就可以进入真正的安装环节了。3. 编译安装 sysstat-11.5.6路径冲突与三行命令验证编译 sysstat 本身不难难的是装完之后系统里到底跑的是哪一份。这一章我把路径决策和编译验证放在一起讲因为这两件事是连在一起的。3.1 决定前缀路径隔离装还是覆盖装我一般会做一个隔离安装把 sysstat 安排到独立目录再通过软链接控制对外暴露的命令这样可以避免和发行版自带的另一套 sysstat 混淆。# 解压源码包 tar -xzf sysstat-11.5.6.tar.gz cd sysstat-11.5.6 # 配置到独立目录显式关闭压缩让行为最可预期 ./configure --prefix/usr/local/sysstat-11.5.6 \ --enable-install-cron \ --disable-compression这里重点说三个参数。--prefix 决定安装根目录我用的是 /usr/local/sysstat-11.5.6这样全部文件收拢在一个目录里之后想整体删掉也不会留垃圾。--enable-install-cron 会让 make install 同时安装 sa1、sa2 脚本到 lib 目录省得自己手写这两个壳。--disable-compression 是我个人偏好它把 configure 探测到的压缩支持显式关掉让日志以最原始格式落盘。压缩能省空间但读取时多一层解压且一旦文件头损坏恢复难度更高。日志大小这件事可以靠 HISTORY 控制天数来解决不值得为此引入额外复杂度。如果源码目录里已经有 configure 生成过的缓存重新配置之前建议先 make distclean避免旧配置项残留影响新的前缀设置。这个小动作能省掉很多莫名其妙的编译期报错。3.2 make 到 install 的验证链配置完成后就是三行命令的事。# 并行编译nproc 取核数 make -j$(nproc) # 安装到指定前缀 make install # 在公共路径建一个软链接方便直接调用 ln -s /usr/local/sysstat-11.5.6/bin/sar /usr/local/bin/sar # 验证版本与路径 /usr/local/sysstat-11.5.6/bin/sar -Vmake -j 后面的数字是并行编译的进程数直接用 nproc 动态获取即可避免手动写死导致编译时负载过高。make install 需要 root 权限因为要写 /usr/local 下的目录如果之前配置时用的非 root 用户这一步会直接报权限不足。软链接那行是把新版本暴露到 PATH 里避免每次敲完整路径。最后的 sar -V 是为了确认我们调用的是 11.5.6 而不是旧版。安装完还要核对一下 sa1、sa2、sadc 的实际位置因为不同 configure 参数下它们可能落在 lib 或 lib64 下。# 查找采集脚本与 sadc 的位置 find /usr/local/sysstat-11.5.6 -name sa1 -o -name sa2 -o -name sadc这一步的输出直接决定后面 cron 脚本里要填的绝对路径。常见做法是先跑一遍 find 记下路径再写配置。如果你需要在多台同构服务器上快速铺开还可以用 DESTDIR 打包把安装内容先落到临时目录再整体拷贝到其他机器省去每台机器都编译一遍的时间。编译期最常碰到的报错基本就三类一是 configure 阶段提示 no acceptable C compiler found说明缺 gcc装上编译器组再回来二是 make 阶段 ld: cannot find -lz说明 zlib 开发头文件没装三是 make install 时提示目录只读说明当前用户权限不够改用 root 执行安装即可。这三类问题我在不同机器上各见过不下十次没有一次是 sysstat 本身的问题全是环境准备不到位。4. 配置采集链路与常用统计项让 sar 真正干活编译安装只是把工具放下真正让 sysstat 产生价值的是采集链路。这一章解决两个问题数据怎么持续进文件以及遇到故障时用什么命令把数据捞出来。4.1 手写 cron 采集链sa1、sa2 与 HISTORY 的配合源码安装不会替你把 crontab 写好所以需要自己动手建一个 /etc/cron.d/sysstat。这是让 sysstat 每 10 分钟自动采集的关键文件也是后续所有历史数据存在的前提。cat /etc/cron.d/sysstat EOF SHELL/bin/sh PATH/usr/local/sysstat-11.5.6/bin:/usr/local/sysstat-11.5.6/lib/sa:/usr/local/bin:/usr/bin:/bin # 每10分钟调用一次 sa1采样间隔1秒采样1次 */10 * * * * root /usr/local/sysstat-11.5.6/lib/sa/sa1 1 1 # 每天23:53调用 sa2 汇总当天数据 53 23 * * * root /usr/local/sysstat-11.5.6/lib/sa/sa2 -A EOFsa1 后面的两个数字分别是采样间隔和采样次数间隔 1 秒、次数 1 次意思就是每个整点十分钟采一个瞬时值。cron 行里的 10 分钟由 */10 控制sa1 本身不决定频率。sa2 -A 里的 -A 表示汇总所有统计项生成当天的数据文件归档。这里有个容易被忽略的点cron 环境非常干净不会自动读取 /etc/sysconfig/sysstat所以如果系统里存在这个配置文件需要在 cron 脚本里显式加载否则里面的 HISTORY 和 SADC_OPTIONS 全部不生效。接着创建 sysstat 自己的配置文件用来控制保留天数和采集范围。cat /etc/sysconfig/sysstat EOF HISTORY14 SA_DIR/var/log/sa SADC_OPTIONS-S XALL EOFHISTORY 是保留多少天的日志文件超过这个天数的 sa 文件会被清理。这个参数适合按磁盘空间设定如果每天日志量在几 MB 量级14 天是个比较舒适的起点。SADC_OPTIONS 传给 sadc-S XALL 表示采集内核提供的全部统计组包括中断、电源、磁盘等扩展项。没有这一项后面 sar -A 读历史时会看到一片全是 0 的字段这是很典型的问题下一章会展开讲。4.2 实时与历史五条命令快速定位瓶颈采集链路跑起来之后日常排查时我用到最多的就是下面五组命令。# CPU 总使用率每1秒采样一次共3次 sar -u 1 3 # 每个 CPU 核心的使用率 mpstat -P ALL 1 2 # 内存使用情况 sar -r 1 3 # 磁盘的吞吐、等待时间与使用率 iostat -x 1 5 # 按进程维度看 CPU 和内存 pidstat -u -r 1 3sar -u 看的是整体 CPU 使用率单核不均衡时它会掩盖问题所以要配合 mpstat -P ALL 看每个核的分布。sar -r 看内存页换入换出如果 pi 和 po 一直有值说明物理内存不够用。iostat -x 里最重要的不是第一眼看到的 %util而是 await 和 avgrq-sz后面避坑章节单独说。pidstat -u -r 组合起来可以同时盯住 CPU 和内存两个维度定位到具体进程再往下查。实时数据只是其中一半另一半是历史回放。# 读回今天的历史数据查看整天 CPU、内存、负载走势 sar -f /var/log/sa/sa$(date %d) -u -r -q-f 指定历史文件文件名里的 sa 后跟的两位数字是当月几号。今天是 15 号就读 sa15不会自动跨月所以要看上个月的数据得自己按文件名去对应目录里找。这个命令在故障复盘时价值极高因为问题往往是过去 24 小时内某个时间点开始积累的从历史数据里能看到拐点。5. 避坑手册sysstat 从安装到读取的 5 个翻车现场这一章写的是我见过最多、也最容易反复踩的五个问题。每一条都按现象、原因、解决的顺序来方便你在现场对照。5.1 装完敲 sar 还是旧版本现象make install 结束却提示找不到命令或版本和预期不一致。原因系统里发行版自带的 sysstat 抢先占据了 PATH输入 sar 时 shell 优先命中 /usr/bin/sar。解决方式# 看当前命中路径 which sar # 再看版本 sar -V # 优先使用隔离目录里的版本 /usr/local/sysstat-11.5.6/bin/sar -V如果确认是路径抢占要么把软链接放到 PATH 更靠前的目录要么在配置文件里调整 PATH 顺序。这个问题没有技术难度但很隐蔽因为系统不报错只是行为不对。5.2 日志目录空的一个 sa 文件都没有现象/var/log/sa 目录存在但里面没有任何文件sar -f 读不到任何数据。原因一般是三个crond 服务没在运行cron 脚本里 sa1 的路径写错或者 /var/log/sa 目录根本不存在sa1 没有权限自动创建。解决方式# 确认 cron 服务在跑 systemctl status crond # 手动执行一次看真实报错 /usr/local/sysstat-11.5.6/lib/sa/sa1 1 1 # 目录不存在则手动创建并设置属主 mkdir -p /var/log/sa chown root:root /var/log/sa手动执行 sa1 是排查这类问题最快的方式它会直接打印出缺失的路径或权限信息比猜快得多。注意 sa1 里的所有路径都要写绝对路径cron 的 PATH 环境非常精简不能依赖相对路径。5.3 HISTORY 设了 7 天日志却留了三十天现象明明在 /etc/sysconfig/sysstat 里写了 HISTORY7但 /var/log/sa 下的文件越来越多清理机制完全没生效。原因cron 执行 sa2 时没有加载 /etc/sysconfig/sysstatHISTORY 在 sa2 的环境里根本不存在。解决方式是在 /etc/cron.d/sysstat 里显式加载配置文件cat /etc/cron.d/sysstat EOF SHELL/bin/sh . /etc/sysconfig/sysstat EOF注意这行加载必须放在调用 sa1、sa2 之前。很多发行版的自动安装脚本会替你做这一步但源码安装时必须自己处理。这个坑的典型症状就是磁盘空间缓慢增长往往要等到 /var 分区告警才会被发现。5.4 iostat 的 %util 显示 100%业务却毫无压力现象iostat -x 输出里磁盘 %util 长期是 100%但应用响应正常没有任何卡顿。原因%util 表示的是设备在采样周期内有未完成命令的时间占比并不直接等于磁盘忙到极限。对高速设备和某些 RAID 控制器来说这个值很容易虚高。解决方式是把它和两个辅助指标一起看iostat -x -d 1 5重点看 await平均 IO 响应时间和 avgrq-sz平均请求大小。await 保持在个位数毫秒、avgrq-sz 正常时%util 虚高可以忽略。11.5.6 里还保留了 svctm 这一列它反映的是命令平均执行时间可以辅助判断设备本身是否处于饱和状态。只看 %util 单挑问题会在排查方向上绕远路。5.5 换服务器后历史文件读不出来或全是 0现象把旧服务器的 sa 文件拷贝到新环境sar -f 直接报文件格式错误或者能打开但读出的字段全是 0。原因sysstat 不同版本之间的数据文件格式并不完全兼容而且 SADC_OPTIONS 采集范围不一致也会读不出扩展统计项。解决方式是保持版本和采集选项一致# 对比两边的 SADC_OPTIONS cat /etc/sysconfig/sysstat # 用新环境读取时会先确认版本 sar -V监控系统的历史数据是有延续性的版本混用会让对比完全失效。这也是我坚持固定 sysstat 版本的原因之一。生产环境的采样配置一旦确定就别因为某次升级顺手改掉宁可先在新机器上并行验证一周再切换。6. 用 sadf 把历史数据导出 CSV出故障后有后悔药6.1 sadf 导出命令sar 输出适合人眼扫但要做故障前后对比、进监控平台二次绘图就得把数据导出成结构化的 CSV。sadf 就是这个出口它把 sa 二进制文件转成文本表格。# 导出当天 09:00 到 18:00 的 CPU、内存、运行队列数据 sadf -d /var/log/sa/sa$(date %d) -s 09:00:00 -e 18:00:00 -- -u -r -q | head -20-d 表示输出制表符分隔的表格-s 和 -e 限定起止时间-- 后面跟的是 sar 的统计项参数。导出的每行有时间戳、主机名、统计类别和数值可以直接丢进脚本或可视化工具。这个命令是我在故障复盘时最常用的比截图留档可靠得多。6.2 建立基线再谈分析我的习惯是每台新服务器装完 sysstat 后先手动采一组 300 秒的基线数据导成 CSV 存起来。日常运维中一旦出现负载异常就导出同一时间窗口的 CSV和基线拼在一起看偏差。有了基线CPU 升高一点、内存换页增多一点都能被量化确认而不是靠感觉判断是不是出了问题。监控工具的价值不在实时界面而在于你能回放过去任意一刻的系统状态。这套流程走下来sysstat-11.5.6.tar.gz 在你手里就不只是一个压缩包而是一条可以持续追溯系统历史状态的完整链路。固定版本、固定选项、固定保留周期是我这几年运维下来最值得坚持的一组习惯。希望帮到你。本文还有配套的精品资源点击获取