sar（System Activity Reporter）是Linux系统中一个强大的性能分析工具，它属于sysstat工具包的一部分，能够实时监控并保存系统的各种性能指标。通过sar，我们不仅能查看当前状态，还能回溯历史数据，从而更准确地定位和解决性能问题。本文将深入解析sar的使用方法和场景，并结合真实案例说明其在系统运维中的价值。
sar的基本概念和安装配置
sar是System Activity Reporter的缩写，它能够收集、报告和保存系统活动信息，类似于给服务器装了一个“黑匣子”。无论是CPU使用率、内存占用、磁盘IO还是网络流量，sar都能记录下来。这种历史数据的保存功能，使得我们在排查间歇性问题时拥有极大的优势。
在大多数Linux发行版中，sysstat包通常是预装的。如果没有安装，可以通过以下命令进行安装：
对于CentOS/RHEL系统：
yum install sysstat
# 或者新版本使用
dnf install sysstat
对于Ubuntu/Debian系统：
apt-get install sysstat
安装完成后，需要启动并启用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文件中。需要注意的是，这些数据文件是二进制格式，不能直接使用cat或vi查看，必须通过sar命令来读取。
CPU监控：揪出那些偷懒的进程
CPU监控是sar最基础、也是最常用的功能之一。我们可以通过-u参数来查看当前CPU的使用情况：
sar -u 1 5
这条命令的意思是：每1秒采样一次，总共采样5次。输出结果通常包含以下字段：
%user: 用户态CPU使用率%nice: 运行在nice优先级下的用户态进程CPU使用率%system: 内核态CPU使用率%iowait: CPU等待IO操作的时间百分比%steal: 虚拟机环境下被其他虚拟机抢占的CPU时间%idle: CPU空闲时间百分比
这些指标中，%user高说明应用程序在拼命干活，%system高可能是系统调用太多或者内核有瓶颈，%iowait高则要检查磁盘IO。对于多核CPU，使用-P参数可以查看每个核心的情况：
sar -u -P ALL 1 3
通过这种方式，我们可以判断CPU负载是否均衡分布在各个核心上。如果发现某个核心负载过高，可能是程序设计不合理，或者存在资源争抢的情况。
内存使用情况：找出内存杀手
内存使用情况的监控可以通过-r参数完成：
sar -r 1 5
输出结果通常包含以下字段：
kbmemfree: 空闲内存（KB）kbmemused: 已使用内存（KB）%memused: 内存使用率kbbuffers: 内核缓冲区使用的内存kbcached: 缓存使用的内存kbcommit: 已提交的内存%commit: 提交内存占总内存的百分比kbactive: 活跃使用的内存kbinact: 不活跃使用的内存
值得注意的是，看到%memused高并不一定意味着内存不够，因为Linux会在空闲内存中使用缓存。真正需要关注的是当应用程序需要内存时，系统能否快速回收这些缓存。因此，结合-S参数查看swap使用情况也是一个好习惯：
sar -S 1 5
如果swap使用率开始上升，这可能意味着内存确实不足，需要考虑增加内存。此外，-B参数可以查看内存分页情况，帮助我们判断系统是否在频繁地进行内存和磁盘之间的数据交换：
sar -B 1 5
输出中的pgpgin/s和pgpgout/s分别表示每秒从磁盘读取和写入的页面数。如果这两个值很高，说明系统在频繁地进行内存和磁盘之间的数据交换，这可能会影响性能。
磁盘IO分析：硬盘也会累
磁盘IO分析是性能监控中的重点之一，可以通过-d参数查看磁盘的IO统计信息：
sar -d 1 5
输出结果通常包含以下字段：
DEV: 磁盘设备名称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情况，可以使用-p参数：
sar -d -p 1 5
这会显示分区名而不是设备名，使分析更直观。
网络流量监控：带宽用到哪了
网络流量监控可以通过-n参数完成，后面可以跟不同的关键字。例如，查看网络接口流量：
sar -n DEV 1 5
输出结果通常包含以下字段：
IFACE: 网络接口名称rxpck/s: 每秒接收的数据包数txpck/s: 每秒发送的数据包数rxkB/s: 每秒接收的KB数txkB/s: 每秒发送的KB数rxcmp/s: 每秒接收的压缩包数txcmp/s: 每秒发送的压缩包数rxmcst/s: 每秒接收的多播包数
这些指标中，rxpck/s和txpck/s分别表示每秒接收和发送的数据包数，rxkB/s和txkB/s则表示每秒接收和发送的KB数。如果发现txpck/s接近理论上限，可能是网络瓶颈或攻击问题。
如果想监控TCP连接状态，可以使用-n TCP参数：
sar -n TCP 1 5
这条命令会显示活跃连接数、新建连接数等信息，对Web服务器的性能分析非常有用。
此外，-n SOCK参数可以查看系统中各种类型的socket数量，包括TCP、UDP、RAW等：
sar -n SOCK 1 5
有时候，网络问题并不是明显的带宽瓶颈，而是连接状态异常。例如，TIME_WAIT状态的连接数暴涨，可能是客户端没有正确复用连接，导致服务器资源浪费。
查看历史数据：时光倒流看问题
sar最强大的地方在于它能够查看历史数据。默认情况下，当天的数据保存在/var/log/sa/saDD文件中，其中DD表示日期。例如，查看今天的CPU使用情况：
sar -u
如果想查看昨天的CPU使用情况，可以使用-f参数指定数据文件：
sar -u -f /var/log/sa/sa14 # 假设昨天是14号
还可以指定时间范围来查看特定时间段内的数据：
sar -u -s 08:00:00 -e 18:00:00
这条命令会显示从早上8点到晚上6点的数据。通过这种方式，我们可以分析问题的时间规律，进而定位问题。
实战案例：用sar解决真实问题
案例1：神秘的CPU占用
有一次用户投诉系统在特定时间变慢，但我们监控显示CPU使用率不高。后来用sar -u查看历史数据，发现问题时段%iowait很高，说明CPU在等待IO。接着用sar -d查看磁盘，发现某个磁盘的await时间异常，最终定位到是备份脚本在高峰期运行导致的IO冲突。
案例2：内存泄漏追踪
有一次应用程序运行一段时间后变慢，怀疑是内存泄漏。通过sar -r查看一周的内存使用趋势，发现kbmemused在持续增长，而且增长很规律。结合应用日志分析，找到了有问题的代码模块。
案例3：网络瓶颈定位
有一次网站访问慢，初步排查CPU和磁盘都正常。用sar -n DEV发现网卡的txpck/s（发包率）接近理论上限，原来是遭到了小包攻击。通过调整网卡参数和防火墙规则解决了问题。
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的过程中，我们也遇到了不少问题。以下是一些常见问题和解决方法：
- 时区问题：sar显示的时间是系统本地时间，如果服务器时区设置不对，看历史数据时容易搞混。建议统一使用UTC时间。
- 数据文件损坏：偶尔会遇到sa文件损坏的情况，这时sar会报错。通常是因为系统异常关机导致的。这种情况下只能删除损坏的文件，没有好的恢复方法。
- 性能影响：虽然sar的开销很小，但在极高负载的系统上，频繁的数据收集还是可能产生影响。如果怀疑sar影响性能，可以临时停止sysstat服务测试一下。
- 磁盘空间：长期运行后，
/var/log/sa/目录会占用不少空间。记得定期检查并清理旧文件。
sar与其他监控工具的对比
经常有人问我sar和top、htop、iostat这些工具有什么区别。简单来说，top类工具适合实时查看当前状态，但不能保存历史数据。iostat专注于磁盘IO，功能比较单一。而sar是一个综合性工具，既能实时监控，又能保存历史数据，还覆盖了系统的方方面面。
在我的日常工作中，通常是这样搭配使用：
- 发现问题时用top、htop快速查看当前状态
- 用sar分析历史趋势，找出问题规律
- 用专门的工具（如iotop、nethogs）深入分析具体问题
对于企业级监控，sar的数据还可以作为Zabbix、Nagios等监控系统的数据源，实现更复杂的监控和报警。现在很多公司都在上云，云服务商通常提供自己的监控工具。但我觉得掌握sar这样的传统工具还是很有必要的，毕竟有些细节问题，还是要靠这些底层工具才能查得清楚。
总结：sar的价值与使用建议
sar这个工具说复杂也复杂，说简单也简单。复杂在于它的参数很多，输出信息量大；简单在于掌握了几个核心用法，就能解决大部分问题。我的建议是先从最基本的CPU（-u）、内存（-r）、磁盘（-d）、网络（-n DEV）监控开始，熟练了再去探索其他功能。最重要的是要结合实际问题去使用，纸上得来终觉浅，绝知此事要躬行。
记住，sar不只是个监控工具，更是个分析工具。它记录的不仅是数字，更是系统运行的轨迹。学会读懂这些轨迹，你就能像福尔摩斯一样从蛛丝马迹中找出问题的真相。现在的系统越来越复杂，容器、微服务、云原生...新技术层出不穷。但无论技术怎么发展，底层的系统资源就那么几样：CPU、内存、磁盘、网络。掌握了sar，你就有了一把万能钥匙，能够打开性能问题的大门。
最后想说的是，工具只是手段，思路才是关键。sar能提供数据，但怎么分析这些数据，怎么从中找出问题，这需要经验的积累。希望这篇文章能帮你在sar的使用路上少走些弯路。如果觉得这篇文章对你有帮助，记得点赞转发，也欢迎在评论区分享你使用sar的经验和遇到的问题。让我们一起在运维这条路上互相学习，共同成长！
关键字列表：
Linux, sar, sysstat, CPU监控, 内存分析, 磁盘IO, 网络流量, 性能问题, 历史数据, 自动化脚本