sar介绍
sar全称System Activity Reporter，翻译过来就是系统活动报告器。它属于sysstat工具包的一部分，可以收集、报告和保存系统活动信息。
简单来说，sar就像是给服务器装了个黑匣子，24小时不间断地记录着系统的各种性能指标。CPU使用率、内存占用、磁盘IO、网络流量...这些数据它都会记录下来，等需要的时候随时可以调出来看。
也就是说它不仅能实时监控，还能保存历史数据。比如查看昨天凌晨3点服务器在干什么？没问题，sar都有记录可以调取。
sar相较于top、htop、iostat这些工具，top类工具适合实时查看当前状态，但不能保存历史数据。iostat专注于磁盘IO，功能比较单一。而sar是个综合性工具，既能实时监控，又能保存历史数据，还覆盖了系统的方方面面。
日常工作中，通常是搭配使用
- 发现问题时用top、htop快速查看当前状态
- 用sar分析历史趋势，找出问题规律
- 用专门的工具（如iotop、nethogs）深入分析具体问题
sar不只是个监控工具，更是个分析工具。它记录的不仅是数字，更是系统运行的轨迹。学会读懂这些轨迹，你就能像福尔摩斯一样从蛛丝马迹中找出问题的真相。
现在的系统越来越复杂，容器、微服务、云原生...新技术层出不穷。但无论技术怎么发展，底层的系统资源就那么几样：CPU、内存、磁盘、网络。掌握了sar，你就有了一把万能钥匙，能够打开性能问题的大门。
安装配置
大部分Linux发行版都预装了sysstat包，如果没有的话安装也很简单：
#CentOS/RHEL系统
yum install sysstat
# 或者新版本用dnf
dnf install sysstat
#Ubuntu/Debian系统：
apt-get install sysstat
#装完之后需要启动服务：
systemctl enable sysstat
systemctl start sysstat默认情况下，sar每10分钟收集一次数据，这个频率对大多数场景够用了。如果你想调整频率，可以编辑/etc/cron.d/sysstat文件。
比如想改成每5分钟收集一次：
*/5 * * * * root /usr/lib64/sa/sa1 1 1数据文件默认保存在/var/log/sa/目录下，文件名格式是saDD（DD是日期）。比如今天是15号，那数据就保存在sa15文件里。
有个小坑要注意，sar的数据文件是二进制格式的，不能直接用cat或vi查看，必须通过sar命令来读取。
sar常见使用场景
CPU监控
CPU监控，这是sar最基础也是最常用的功能。
查看当前CPU使用情况：sar -u 1 5
这条命令的意思是每1秒采样一次，总共采样5次。输出大概是这样的：
03:25:01 PM CPU %user %nice %system %iowait %steal %idle
03:25:02 PM all 2.50 0.00 1.25 0.00 0.00 96.25
03:25:03 PM all 3.75 0.00 1.25 0.00 0.00 95.00每个字段的含义：
- %user: 用户态CPU使用率
- %nice: 运行在nice优先级下的用户态进程CPU使用率
- %system: 内核态CPU使用率
- %iowait: CPU等待IO操作的时间百分比
- %steal: 虚拟机环境下被其他虚拟机抢占的CPU时间
- %idle: CPU空闲时间百分比
一般需要关注这几个指标：%user高说明应用程序在拼命干活，%system高可能是系统调用太多或者内核有瓶颈，%iowait高就要检查磁盘IO了。
如果服务器是多核的，可以用-P参数查看每个CPU核心的情况：sar -u -P ALL 1 3
这样就能看出负载是否均衡分布在各个核心上了。
内存使用情况
内存监控用-r参数：sar -r 1 5
输出类似这样：
03:30:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact
03:30:02 PM 1048576 3145728 75.00 102400 524288 2621440 62.50 1572864 786432关键指标解释：
- kbmemfree: 空闲内存（KB）
- kbmemused: 已使用内存（KB）
- %memused: 内存使用率
- kbbuffers: 内核缓冲区使用的内存
- kbcached: 缓存使用的内存
- kbcommit: 已提交的内存
- %commit: 提交内存占总内存的百分比
这里有个常见误区，看到%memused很高就以为内存不够用了。其实Linux会把空闲内存用作缓存，真正需要关注的是当应用程序需要内存时，系统能否快速回收这些缓存。
因此一般会结合swap使用情况一起看：sar -S 1 5
如果swap使用率开始上升，那就真的需要考虑加内存了。
还有个很有用的参数-B，可以查看内存分页情况：sar -B 1 5
输出中的pgpgin/s和pgpgout/s分别表示每秒从磁盘读取和写入的页面数。如果这两个值很高，说明系统在频繁地进行内存和磁盘之间的数据交换。
磁盘IO分析
磁盘IO监控是性能分析的重头戏，用-d参数：sar -d 1 5
输出会列出每个磁盘设备的IO统计信息：
03:35:01 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
03:35:02 PM dev8-0 15.84 0.00 253.47 16.00 0.02 1.25 0.63 10.00重点关注这几个指标：
- tps: 每秒传输次数（IOPS）
- rd_sec/s: 每秒读取扇区数
- wr_sec/s: 每秒写入扇区数
- avgqu-sz: 平均队列长度
- await: 平均等待时间（毫秒）
- svctm: 平均服务时间（毫秒）
- %util: 磁盘利用率
%util这个指标特别重要，如果接近100%说明磁盘已经满负荷了。但这里有个陷阱，对于SSD来说，%util达到100%不一定意味着性能瓶颈，因为SSD可以并行处理多个IO请求。
await时间也很关键，如果这个值很高，用户就会感觉系统响应慢。我一般认为机械硬盘await超过20ms，SSD超过5ms就需要注意了。
想看具体某个分区的IO情况，可以这样：sar -d -p 1 5
-p参数会显示分区名而不是设备名，这样看起来更直观。
网络流量监控
网络监控用-n参数，这个参数后面可以跟不同的关键字：
查看网络接口流量：sar -n DEV 1 5
输出类似：
03:40:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
03:40:02 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:40:02 PM eth0 125.74 89.11 78.32 15.67 0.00 0.00 0.50- rxpck/s, txpck/s: 每秒接收和发送的数据包数
- rxkB/s, txkB/s: 每秒接收和发送的KB数
- rxcmp/s, txcmp/s: 每秒接收和发送的压缩包数
如果你想监控TCP连接状态：sar -n TCP 1 5
这个命令会显示活跃连接数、新建连接数等信息，对于web服务器来说很有用。
还有个很有意思的参数SOCK：sar -n SOCK 1 5
可以看到系统中各种类型socket的数量，包括TCP、UDP、RAW等。
有次我们的web服务突然变慢，用sar -n TCP一看，发现TIME_WAIT状态的连接数暴涨，原来是客户端没有正确复用连接导致的。
查看历史数据
sar最强大的地方就是能查看历史数据。默认情况下，当天的数据保存在/var/log/sa/saDD文件中。
查看今天的CPU使用情况：sar -u
查看昨天的：sar -u -f /var/log/sa/sa14 # 假设昨天是14号
还可以指定时间范围：sar -u -s 08:00:00 -e 18:00:00
这样就只看早上8点到晚上6点的数据了。
这个功能经常用来分析问题的时间规律。比如用户反馈下午系统慢，就会看看下午时段的各项指标，往往能很快定位到问题。
有个小技巧，如果你想生成一份漂亮的报告，可以把sar的输出重定向到文件：
sar -A -f /var/log/sa/sa15 > system_report_15.txt
-A参数表示输出所有统计信息，这样就得到了一份完整的系统性能报告。
sar的进阶用法和小技巧
除了基本的监控功能，sar还有一些很实用的进阶技巧。
自定义输出格式
可以用-j参数将输出转换为JSON格式，方便程序处理：sar -u -j 1 3
这个功能在写自动化脚本时特别有用。
监控特定进程
虽然sar本身不能监控单个进程，但可以结合其他工具。比如先用ps找到进程PID，然后用pidstat（也是sysstat包的一部分）：pidstat -p 1234 1 5
数据文件管理
sar的数据文件会越来越大，需要定期清理。默认保存一个月，可以通过修改/etc/sysconfig/sysstat文件中的HISTORY参数来调整：HISTORY=7 # 只保存7天
结合其他工具
sar输出的数据可以很方便地导入到Excel或者其他分析工具中。我经常把一周的数据导出来，用Excel做个图表，这样趋势就很明显了。
还可以写个简单的脚本，定期提取关键指标并发送邮件报告：
#!/bin/bash
echo "昨日系统性能摘要：" > /tmp/daily_report.txt
echo "CPU使用率：" >> /tmp/daily_report.txt
sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | tail -1 >> /tmp/daily_report.txt
echo "内存使用率：" >> /tmp/daily_report.txt
sar -r -f /var/log/sa/sa$(date -d yesterday +%d) | tail -1 >> /tmp/daily_report.txt
mail -s "日报" admin@company.com < /tmp/daily_report.txt常见问题
用sar这么多年，也踩过不少坑，总结几个常见问题：
时区问题
sar显示的时间是系统本地时间，如果服务器时区设置不对，看历史数据时容易搞混。建议统一使用UTC时间。
数据文件损坏
偶尔会遇到sa文件损坏的情况，这时sar会报错。通常是因为系统异常关机导致的。这种情况下只能删除损坏的文件，没有好的恢复方法。
性能影响
虽然sar的开销很小，但在极高负载的系统上，频繁的数据收集还是可能产生影响。如果怀疑sar影响性能，可以临时停止sysstat服务测试一下。
磁盘空间
长期运行后，/var/log/sa/目录会占用不少空间。记得定期检查并清理旧文件。
实战案例
案例1：神秘的CPU占用
有次用户投诉系统在特定时间变慢，但我们监控显示CPU使用率不高。后来用sar -u查看历史数据，发现问题时段%iowait很高，说明CPU在等待IO。接着用sar -d查看磁盘，发现某个磁盘的await时间异常，最终定位到是备份脚本在高峰期运行导致的IO冲突。
案例2：内存泄漏追踪
应用程序运行一段时间后变慢，怀疑是内存泄漏。通过sar -r查看一周的内存使用趋势，发现kbmemused在持续增长，而且增长很规律。结合应用日志分析，找到了有问题的代码模块。
案例3：网络瓶颈定位
网站访问慢，初步排查CPU和磁盘都正常。用sar -n DEV发现网卡的txpck/s（发包率）接近理论上限，原来是遭到了小包攻击。通过调整网卡参数和防火墙规则解决了问题。
评论 (0)