在CentOS服务器上做运维复盘，最怕的就是出了问题却没有历史数据可查。sar（System Activity Reporter）是sysstat工具包自带的性能采集命令，它能按固定间隔记录CPU、内存、磁盘I/O、网络、进程等核心指标，数据默认保存在/var/log/sa/目录下，文件名格式为saDD（DD为当月日期）。只要提前装好sysstat并开启了数据采集服务，你就能在事后通过sar -f命令回溯任意时间段的系统状态，这是做故障复盘和性能分析最基础也最实用的手段。
一、为什么复盘必须依赖sar历史数据
很多运维同学平时只盯着实时监控看，一旦服务器出了故障或者性能抖动，想回头查原因的时候发现什么记录都没有。实时监控只能告诉你"现在"怎么样，但复盘需要的是"当时"怎么样。比如凌晨三点数据库突然慢了，你需要知道那个时间点CPU是不是打满了、磁盘IO是不是飙高了、是不是有异常进程在跑。sar就是干这个事的——它像一个不间断的黑匣子，默默记录着系统每一秒的运行状态。
二、CentOS上安装和配置sysstat
CentOS 7和CentOS 8/Stream都自带sysstat包，但默认可能没装或者没启用。先检查是否安装：
rpm -qa | grep sysstat
如果没有输出，执行安装：
yum install sysstat -y
装完之后最关键的一步是启用数据采集服务，否则sar不会自动写历史文件：
systemctl enable sysstat systemctl start sysstat
CentOS 7上默认采集间隔是10分钟（600秒），CentOS 8/Stream默认也是10分钟。如果你想采集更细的粒度，比如每分钟一次，需要修改配置文件：
vi /etc/cron.d/sysstat
把里面的*/10改成*/1，表示每分钟采集一次。改完之后重启crond服务：
systemctl restart crond
注意：采集频率越高，产生的数据文件越大，磁盘占用也越多，根据实际需求平衡就行。一般生产环境10分钟足够，如果是关键业务服务器可以调到1-5分钟。
三、sar命令的核心用法和复盘场景
sar的基本语法是sar [选项] [时间间隔] [次数]。但做复盘的时候，我们主要用-f参数指定历史文件来读取。假设今天是15号，你要查昨天的数据：
sar -f /var/log/sa/sa14
这会输出昨天全天每10分钟一个采样点的所有指标。如果只想看某个时间段，比如昨天凌晨2点到4点：
sar -f /var/log/sa/sa14 -s 02:00:00 -e 04:00:00
这里-s是开始时间，-e是结束时间，格式是HH:MM:SS。这个功能在复盘时非常好用，直接锁定故障发生的时间窗口。
四、CPU性能复盘——用sar看处理器负载
查CPU历史数据用sar -u。输出包含几个关键列：%user（用户态CPU占比）、%system（内核态占比）、%iowait（等待IO的CPU占比）、%idle（空闲占比）、%steal（被虚拟化偷走的占比）。复盘时重点看%iowait和%user。
比如你发现某个时间段%iowait飙到了80%以上，说明当时磁盘IO是瓶颈。如果%user很高但%iowait不高，说明是应用层计算密集。还有一个容易忽略的指标是%steal，如果你的服务器是云主机或者虚拟机，%steal高意味着宿主机资源争抢严重。
sar -u -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00
五、内存性能复盘——用sar看内存和交换区使用
查内存用sar -r。关键指标包括：kbmemfree（空闲内存）、kbmemused（已用内存）、kbbuffers（缓冲区）、kbcached（缓存）、kbcommit（承诺内存）、%commit（内存承诺比例）。
复盘时要特别关注%commit这个值。如果%commit超过100%，说明系统曾经出现过内存超卖的情况，这时候OOM Killer可能会杀掉进程。如果你发现某个时间点kbmemfree接近0同时swap使用量在涨，基本可以判断是内存不足导致的性能下降。
sar -r -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00
六、磁盘I/O复盘——用sar看读写瓶颈
查磁盘IO用sar -b（块设备）或者sar -d（有时和-b一样，取决于版本）。关键指标：tps（每秒传输次数）、rtps（每秒读次数）、wtps（每秒写次数）、await（平均等待时间，单位毫秒）、%util（设备利用率）。
复盘磁盘问题时，%util接近100%说明磁盘已经饱和，await如果超过20-30ms对于SSD来说就算高了，机械硬盘超过50ms就需要关注。如果你发现某个时间段tps突然暴涨同时await飙升，大概率是有大量IO操作在跑，可能是备份任务、日志写入或者数据库全表扫描。
sar -b -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00
七、网络性能复盘——用sar看网卡流量
查网络用sar -n DEV（网卡设备）或者sar -n EDEV（网络错误统计）。关键指标：IFACE（网卡名）、rxpck/s（每秒收包数）、txpck/s（每秒发包数）、rxkB/s（每秒收字节）、txkB/s（每秒发字节）、rxcmp/s（每秒压缩包）、txcmp/s（每秒压缩包）。
如果复盘时发现某个时间点rxkB/s突然打满带宽，结合CPU和IO数据一起看，就能判断是不是遭受了流量攻击或者有异常下载任务。EDEV里的err/s和drop/s如果持续升高，说明网卡或链路有问题。
sar -n DEV -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00
八、进程级复盘——用sar看谁在消耗资源
sar -q可以查看运行队列长度和平均负载，sar -w可以看上下文切换和进程创建情况。但更细粒度的进程级数据，sar本身记录的有限，建议配合其他手段。
不过sar -u和sar -r的输出里会包含进程相关的统计，比如proc/s（每秒创建进程数）、cswch/s（每秒上下文切换次数）。如果某个时间段cswch/s异常高，说明系统在频繁切换进程，可能是大量短生命周期进程在跑，或者锁竞争严重。
sar -w -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00
九、复盘实战：如何把sar数据和故障时间线对上
真正做复盘的时候，不是单独看某一个指标，而是把多个指标放在同一时间窗口里交叉比对。比如你知道故障发生在凌晨3:15左右，那就把CPU、内存、磁盘、网络四个维度的数据全部拉出来，时间范围设为03:00到03:30，然后画一个简单的时间线表格。
举个实际例子：某次数据库慢查询，通过sar复盘发现03:10左右%iowait从5%飙到75%，同时磁盘await从3ms涨到80ms，tps从200涨到1500，而CPU的%user只有30%没怎么变。结论很明显——不是计算问题，是磁盘IO被打满了。再结合当时的crontab发现凌晨3点有一个全量备份任务在跑，问题就定位了。
建议把sar数据导出成CSV格式方便做进一步分析：
sar -u -f /var/log/sa/sa14 -s 03:00:00 -e 03:30:00 | awk '{print $1","$2","$3","$4","$5","$6","$7}' > cpu_0300_0330.csv
十、sar数据保存策略和注意事项
sar的历史文件默认保留28天（CentOS 7）或者根据/etc/cron.d/sysstat里的HISTORY变量设置。如果你需要更长时间的数据用于长期趋势分析，建议把旧的sa文件归档到其他存储或者备份服务器上。可以写一个简单的cron脚本每月初把上月的sa文件打包移走：
0 2 1 * * tar czf /backup/sa/sa$(date -d 'last month' +%m).tar.gz /var/log/sa/sa$(date -d 'last month' +%d) 2>/dev/null; rm -f /var/log/sa/sa$(date -d 'last month' +%d)
另外要注意，sar数据是二进制格式存储的（通过sadc采集），不能直接用cat看，必须用sar -f来读取。如果文件损坏或者被误删，那就没办法恢复了，所以备份很重要。
十一、常见误区和补充建议
很多人以为装了sysstat就万事大吉了，但实际上如果服务器重启过，重启期间的数据是没有的。sar只记录运行期间的数据，重启那一段是空白。所以如果你的故障恰好发生在重启后不久，sar帮不了你，需要配合其他监控手段。
还有一点，sar采集的是系统级指标，对于应用层的细粒度数据（比如某个SQL执行了多久、某个接口响应了多少毫秒）它是无能为力的。复盘的时候sar负责提供系统层面的背景信息，应用层数据需要从APM工具或者日志里获取，两者结合才能形成完整的故障画像。
最后说一句，sar是最轻量、最无侵入的性能采集方式，不需要装agent，不需要改应用代码，对系统性能影响几乎可以忽略。对于CentOS运维来说，这是性价比最高的历史数据采集方案，没有之一。把它配好、用好，复盘的时候你就不会两眼一抹黑了。
