ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

sysstat 11.5.6 源码编译与实战:iostat、sar 性能监控工具链部署指南

sysstat 11.5.6 源码编译与实战:iostat、sar 性能监控工具链部署指南 简介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 头文件、25 个 in 模板、35 个 po 多语言文件为主另含 configure 脚本、man 手册、cron 配置与示例数据覆盖编译、安装与本地化所需资源。已有 470 人学习下载。通过该源码包读者可自行编译部署 sysstat掌握各监控工具的采集机制与报表定制方法为服务器调优与故障排查提供数据支撑。1. sysstat 11.5.6.tar.gz 到底装了什么从 iostat 到 sar 的完整工具链如果你在 Linux 上排查过磁盘 IO 瓶颈大概率敲过iostat -x 1。但很多人不知道这条命令背后是一整套叫 sysstat 的工具集而sysstat-11.5.6.tar.gz就是它的源码发布包。这个 tar.gz 解压后包含十几个命令行工具iostat 看磁盘和 CPUsar 做历史数据回放mpstat 看多核负载pidstat 按进程维度拆解资源占用还有 sadf 负责把二进制数据转成 JSON、XML、CSV 等格式。它解决的核心问题是让你在不装额外 agent 的前提下拿到系统级的性能时间线。适合运维、后端开发、数据库调优和任何需要定位“机器为什么变慢”的人。源码包意味着你可以自己编译控制安装路径和编译选项而不是被发行版仓库里的版本锁死。2. 编译安装 sysstat 11.5.6configure 参数与 systemd 单元配置2.1 为什么选源码编译而不是直接 yum/apt 装发行版仓库里的 sysstat 版本往往偏旧比如 CentOS 7 默认带的是 10.x缺少 11.x 里对某些新内核指标的支持。另外仓库安装会把文件散落到/usr/bin、/etc/sysconfig、/usr/lib/systemd/system等多个位置如果你只想在特定目录下部署一套独立工具链源码编译更干净。常见做法是解压后先看INSTALL文件再用./configure --prefix/opt/sysstat指定安装前缀这样所有二进制、配置和库都收在/opt/sysstat下不污染系统路径。2.2 编译前的依赖检查与 configure 关键参数sysstat 11.5.6 依赖不多但少了会直接编译失败。我一般先跑一遍# 检查基础编译工具链 gcc --version make --version # 检查可选的依赖没有也能编但会少功能 rpm -qa | grep -E gettext|libtool|autoconf如果要用sadf输出 JSON 格式需要确保系统里有gettext和libtool。configure 阶段有几个参数值得注意tar -xzf sysstat-11.5.6.tar.gz cd sysstat-11.5.6 ./configure \ --prefix/opt/sysstat \ --disable-man-group \ --enable-collect-all--prefix决定安装根目录--disable-man-group跳过 man 手册的组权限设置避免在容器里报错--enable-collect-all打开全部数据采集项包括中断、上下文切换、内存分页等。如果你只关心磁盘和 CPU可以不加最后一项减少采集开销。2.3 编译、安装与 systemd 单元文件configure 通过后直接make -j$(nproc) sudo make install装完后二进制在/opt/sysstat/bin配置文件在/opt/sysstat/etc。接下来要让 sar 能按周期采集数据需要配置 systemd 单元。sysstat 源码包里自带sysstat.service模板但路径是按默认前缀写的需要改# /etc/systemd/system/sysstat.service [Unit] Descriptionsysstat data collector Afternetwork.target [Service] Typesimple ExecStart/opt/sysstat/lib/sa/sadc -F -L -S DISK -S INT -S IP -S ETC -S SNMP 60 10 /var/log/sa/sa$(date %d) Restartalways [Install] WantedBymulti-user.targetsadc是数据采集守护进程-S DISK表示采集磁盘统计-S INT采集中断60 10表示每 60 秒采一次、共采 10 次后退出然后 systemd 的Restartalways会重新拉起形成循环。/var/log/sa/sa$(date %d)是按天分文件方便 sar 回放。注意sadc的采集间隔不要低于 10 秒否则在高 IO 场景下自身会成为负载来源。生产环境常用 60 秒或 300 秒。2.4 验证安装是否成功装完先跑一条最简单的命令确认二进制可用/opt/sysstat/bin/iostat -V # 应输出 sysstat 版本号 11.5.6 /opt/sysstat/bin/sar -V # 同样输出版本号然后手动触发一次采集看数据文件是否生成sudo /opt/sysstat/lib/sa/sadc -F -L 1 1 /tmp/test_sa ls -lh /tmp/test_sa # 应该看到一个几十 KB 的二进制文件用 sadf 把这个文件转成可读文本/opt/sysstat/bin/sadf -d /tmp/test_sa -- -u # -d 表示从文件读-- 后面跟 sar 的参数-u 表示看 CPU如果能看到 CPU 使用率表格说明采集、存储、回放这条链路是通的。3. iostat 与 sar 实战参数组合、输出解读与数据回放3.1 iostat -x 的字段含义与常见误读iostat -x 1是排查磁盘瓶颈的起手式但很多人只看%util这是不够的。先看一个典型输出/opt/sysstat/bin/iostat -x 1 3关键字段字段含义关注点r/s, w/s每秒读/写次数结合 await 看是否偏高rkB/s, wkB/s每秒读/写千字节看吞吐是否达到设备上限await平均 IO 等待时间ms超过 20ms 通常有问题svctm平均服务时间ms11.x 里已标记为废弃别依赖%util设备繁忙百分比接近 100% 不一定就是瓶颈%util的坑在于对于 SSD 和 RAID即使%util到 100%设备仍可能有余力因为它是按“有 IO 在飞”的时间比例算的不反映队列深度。更可靠的指标是aqu-sz平均队列长度和await。如果await高但%util不高说明 IO 调度或后端存储有问题。3.2 sar 回放历史数据从 sa 文件到时间线sar 的价值在于“事后复盘”。当系统在凌晨三点卡顿你不可能当时守着终端但 sadc 已经把数据写进了/var/log/sa/sa15这样的文件。回放命令# 看指定日期的 CPU 使用率 /opt/sysstat/bin/sar -f /var/log/sa/sa15 -u # 看磁盘 IO-d 表示磁盘-p 表示带设备名 /opt/sysstat/bin/sar -f /var/log/sa/sa15 -d -p # 看内存和交换分区 /opt/sysstat/bin/sar -f /var/log/sa/sa15 -r -S-s和-e可以限定时间范围/opt/sysstat/bin/sar -f /var/log/sa/sa15 -s 02:00:00 -e 04:00:00 -u这样就能精确回放凌晨两点到四点的 CPU 曲线。如果发现%iowait在这段时间飙升再切到-d看是哪块盘、哪个操作类型导致的。3.3 pidstat 按进程拆解定位到具体 PID系统级指标只能告诉你“有瓶颈”pidstat 才能告诉你“谁在制造瓶颈”。常用组合# 每 2 秒采样一次共 5 次按 CPU 排序 /opt/sysstat/bin/pidstat -u 2 5 # 按磁盘 IO 排序-d 表示 IO 统计 /opt/sysstat/bin/pidstat -d 2 5 # 看指定进程的内存和缺页 /opt/sysstat/bin/pidstat -r -p 12345 2 5pidstat -d的输出里kB_rd/s和kB_wr/s是进程级的读写速率iodelay是 IO 延迟。如果某个进程的iodelay持续偏高说明它在等 IO而不是在算。这时候再结合iostat -x看是哪块盘的问题链路就完整了。3.4 sadf 转 JSON把性能数据接入监控管道sysstat 的二进制 sa 文件不方便直接给外部系统消费sadf 可以转成 JSON/opt/sysstat/bin/sadf -j /var/log/sa/sa15 -- -u -d输出是标准 JSON可以直接用 jq 解析或者喂给 Logstash、Fluentd 之类的管道。如果你在搭建轻量级性能监控又不想上 Prometheus node_exportersadf 定时任务 对象存储是一条很省事的路线。常见做法是每天凌晨把前一天的 sa 文件转成 JSON 压缩归档保留 30 天。4. 避坑与排查sysstat 11.5.6 部署中最容易翻车的五个点4.1 采集间隔设成 1 秒结果系统更卡了现象配置 sadc 每 1 秒采集一次发现系统负载反而升高iostat 自身占用明显。原因sadc 每次采集要读取/proc/stat、/proc/diskstats等文件高频采集时这些读取本身会产生开销尤其在容器或小规格云主机上。解决生产环境采集间隔不低于 60 秒。如果确实需要秒级精度用iostat -x 1临时抓取不要改 sadc 的周期。4.2 sar 回放报 “Cannot open /var/log/sa/sa15: No such file or directory”现象明明 sadc 在跑但 sar -f 找不到文件。原因sadc 的写入路径和 sar 的默认读取路径不一致。源码编译安装时默认路径可能被 prefix 改变而 sar 仍去/var/log/sa找。解决用sar -f显式指定完整路径或者在/opt/sysstat/etc/sysconfig/sysstat里改SA_DIR变量让 sadc 和 sar 指向同一个目录。4.3 iostat 输出里设备名是 dm-0、dm-1看不出对应哪块盘现象iostat -x只显示 dm 设备没有 sda、nvme0n1。原因LVM 或加密层把物理设备映射成了 device-mapper 设备iostat 默认只显示顶层。解决加-N参数显示 LVM 逻辑卷名或者用lsblk先理清 dm 和物理盘的对应关系。如果还是看不到物理盘检查/proc/diskstats里是否有对应条目。4.4 编译时提示 “Cannot find libgettextlib”现象./configure报错找不到 gettext 相关库。原因系统缺少 gettext 开发包sadf 的 JSON/XML 输出依赖它做国际化。解决CentOS 上yum install gettext-develDebian/Ubuntu 上apt install gettext。如果不需要 JSON 输出可以在 configure 时加--disable-gettext跳过。4.5 systemd 服务启动后立即退出状态显示 “inactive (dead)”现象systemctl start sysstat后马上变成 dead日志里没有明显报错。原因sadc 的-S参数里包含了当前内核不支持的采集项sadc 启动后直接退出。比如在某些容器环境里-S SNMP会失败。解决先用sadc -F -L 1 1 /tmp/test手动跑一次看报错信息。然后从 systemd 单元里去掉不支持的-S项只保留DISK、INT、IP这些通用项。5. 进阶技巧用 sadf 做自定义报表与数据保留策略5.1 用 sadf 输出 CSV 并做二次计算sadf 支持-c输出 CSV适合丢进 Excel 或 pandas 做趋势分析/opt/sysstat/bin/sadf -c /var/log/sa/sa15 -- -u -d /tmp/sa15.csvCSV 第一行是表头后面每行是一个时间点的数据。用 pandas 读进来后可以算%iowait的 95 分位、await的滑动平均甚至做异常检测。我一般会写一个定时脚本每天把前一天的 CSV 生成好存到/data/sysstat/csv/下保留 90 天。5.2 数据保留策略sa 文件怎么清理sadc 默认按天写文件一个月下来/var/log/sa会积累 30 个左右的文件每个几十 MB。如果不清理一年就是几个 GB。常见做法是用 logrotate 或者 cron 定时删除# 删除 30 天前的 sa 文件 find /var/log/sa -name sa[0-9][0-9] -mtime 30 -delete注意不要删掉sa目录本身和sar的符号链接。如果你用/opt/sysstat前缀路径要相应调整。5.3 验证采集完整性用 sadf 检查时间戳连续性sadc 偶尔会因为系统休眠、时钟跳变或 OOM 而漏采。验证方法是用 sadf 输出时间戳看间隔是否均匀/opt/sysstat/bin/sadf -j /var/log/sa/sa15 -- -u | jq .sysstat.hosts[0].statistics[0].timestamp如果发现某两个时间戳之间差了 10 分钟以上说明中间有漏采。这时候要检查 systemd 的Restartalways是否生效以及/var/log/sa所在分区是否满了。5.4 一个我踩过的坑时区与 sar 时间显示sar 默认按系统时区显示时间但如果你的服务器时区是 UTC而你看日志时按本地时间找就会对不上。我习惯在部署时统一设成Asia/Shanghai并且在 sar 命令里加-t参数强制显示本地时间。另外sadc 写入的时间戳是 UTC 的sadf 转换时会按当前时区渲染所以跨时区迁移服务器后历史数据的回放时间会偏移。从那以后我每次部署 sysstat 都强制走一遍时区检查确认timedatectl和/etc/localtime一致再启动采集。希望帮到你。本文还有配套的精品资源点击获取
返回列表