1. 项目概述：为什么我们需要一个“系统健康档案管理员”
在Linux运维和性能调优的日常工作中，我们常常扮演着“救火队员”的角色。系统突然变慢，CPU使用率飙升，内存告急，网络延迟陡增……当这些问题发生时，第一反应往往是手忙脚乱地敲下top、free -h、vmstat等命令，试图抓住现场的蛛丝马迹。然而，这种“事后诸葛亮”式的排查，往往只能看到问题发生时的瞬时状态，对于问题的根源、发生频率、发展趋势，我们一无所知。这就好比医生看病，只看病人当下的体温，却不知道他过去一周的体温变化曲线，诊断的难度和准确性都会大打折扣。
这时，sar命令的价值就凸显出来了。它不是一个简单的瞬时监控工具，而是一个默默无闻的“系统健康档案管理员”。它能够以固定的时间间隔，持续、系统地收集CPU、内存、磁盘I/O、网络、进程活动等数十种关键性能指标，并将这些数据归档保存。当我们需要回溯分析性能瓶颈、进行容量规划，或者仅仅是想了解系统的“作息规律”时，这些历史数据就是最宝贵的“病历本”。
但是，默认情况下，大多数Linux发行版（如CentOS/RHEL）的sar工具（来自sysstat包）虽然会自动收集数据，但其历史数据通常只保留最近几天（例如7天）。对于需要长期趋势分析、月度报告或审计的场景，这远远不够。因此，一个常见的、刚需的运维实践就是：配置sar自动收集性能数据，并确保其历史信息能完整保存30天甚至更久。这个项目，就是围绕这个核心需求，从原理、配置、实操到问题排查，进行一次彻底的梳理和实现。
2. 核心工具解析：sysstat套件与sar命令的深度剖析
2.1 sysstat套件：不只是sar
很多人以为sar就是一个独立的命令，其实它是一个名为sysstat的工具集的一部分。理解这个套件，是玩转系统监控的基础。
sysstat套件主要包含以下几个核心工具：
sar(System Activity Reporter)：核心工具，用于收集、报告和保存系统活动信息。它既能查看实时数据，也能读取历史数据文件。sadc(System Activity Data Collector)：系统活动数据收集器。它是sar的后台引擎，一个二进制守护进程，负责按预定间隔将性能数据写入日志文件。我们配置的自动收集任务，本质上就是配置sadc的运行方式。sa1和sa2：这是两个Shell脚本，是连接用户配置和sadc的桥梁。sa1：调用sadc进行一次数据收集，并写入当日的数据文件。sa2：生成一个易于阅读的每日总结报告。它实际上调用sar命令，并带上各种参数，来生成一个涵盖全天各项指标的汇总报告。
iostat、mpstat、pidstat等：这些是用于查看特定资源（如磁盘I/O、CPU、进程）实时状态的工具，它们也属于sysstat包，并且能很好地与sar的历史数据视角互补。
注意：在配置自动收集时，我们通常不直接操作
sadc，而是通过配置cron定时任务来调用sa1和sa2脚本。sysstat包安装后，通常会自带这些定时任务的配置模板。
2.2 sar命令的数据存储机制
sar收集的数据存放在哪里？这是配置长期保存的关键。默认路径是/var/log/sa/目录（在某些系统上可能是/var/log/sysstat/）。
在这个目录下，你会看到两类文件：
saXX文件：这是二进制数据文件，其中XX代表当月的日期（01-31）。例如，sa10就是本月10号那天的详细性能数据原始记录。sadc收集的数据就写在这里。文件较小，但包含所有原始细节。sarXX文件：这是文本格式的每日总结报告文件，同样XX代表日期。它是由sa2脚本调用sar生成的，内容是人类可读的，包含了当天各项指标的摘要（如CPU全天平均使用率）。文件相对较大。
数据保留的逻辑：sysstat服务通过一个名为sysstat的cron定时任务（通常位于/etc/cron.d/sysstat）来每天执行一次清理工作。这个任务会读取一个配置文件，决定保留多少天的历史数据。默认通常是7天或更少。我们的核心目标，就是修改这个清理逻辑，让它保留30天的数据。
3. 实战部署：配置自动收集与30天数据保留策略
下面我们进入实操环节。我将以 CentOS 7/RHEL 7 及更新版本（使用systemd）为例，演示完整的配置过程。其他发行版如 Ubuntu，原理相通，只是包管理器和部分文件路径略有差异。
3.1 安装与基础检查
首先，确保sysstat工具包已经安装。大多数现代Linux发行版会默认安装，但最好确认一下。
# 检查是否已安装 rpm -qa | grep sysstat # CentOS/RHEL # 或 dpkg -l | grep sysstat # Ubuntu/Debian # 如果未安装，则进行安装 sudo yum install sysstat -y # CentOS/RHEL # 或 sudo apt-get install sysstat -y # Ubuntu/Debian安装后，关键的配置文件是/etc/sysconfig/sysstat（CentOS/RHEL）或/etc/default/sysstat（Ubuntu/Debian）。这个文件控制了sadc数据收集器的行为。
# 查看默认配置 cat /etc/sysconfig/sysstat你会看到类似以下内容：
# How long to keep log files (in days). # If value is greater than 28, then log files are kept in # multiple directories, one for each month. HISTORY=28 # Parameters for the system activity data collector (see sadc manual page) # which are used for the generation of log files. SADC_OPTIONS="-S DISK" # Compression program to use. ZIP="bzip2"HISTORY=28：这是控制历史数据保留天数的关键参数！注意，注释里明确说了，如果值大于28，日志文件会按月分目录存储。默认28天已经接近30天，但为了确保整整30天，我们通常就设置为30。SADC_OPTIONS="-S DISK"：sadc的选项。-S指定要收集的数据类型，DISK表示收集磁盘统计信息。你可以根据需要添加其他选项，如-S XDISK收集扩展磁盘统计，-S POWER收集电源管理统计等（具体见man sadc）。ZIP="bzip2"：指定用于压缩旧日志文件的程序。bzip2压缩率高但较慢，也可以改为gzip或xz。
3.2 关键配置：修改数据保留策略
我们的目标是保留30天数据。直接修改/etc/sysconfig/sysstat文件：
sudo vi /etc/sysconfig/sysstat将HISTORY参数的值修改为30：
HISTORY=30保存并退出。这个修改意味着sysstat的日志清理脚本（后面会讲到）将保留最近30天的saXX和sarXX文件。
3.3 配置数据收集频率与启用服务
sysstat的数据自动收集由两个部分组成：高频的详细数据收集和每日的报告生成。
1. 高频数据收集 (sa1)： 这个任务由cron调度。配置文件通常位于/etc/cron.d/sysstat。我们查看一下：
cat /etc/cron.d/sysstat内容通常如下：
# Run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib64/sa/sa1 1 1 # 0 * * * * root /usr/lib64/sa/sa1 600 6 & # Generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib64/sa/sa2 -A- 第一行：
*/10 * * * *表示每10分钟运行一次sa1 1 1。这里的参数1 1意思是：采样间隔1秒，采样1次。但结合cron的10分钟一次，它实际上是每10分钟收集一次过去10分钟内的“1秒快照”的汇总数据。这是默认的、最常用的配置，在数据量和精度间取得了平衡。 - 第二行（被注释）：这是一个备选方案，每小时运行一次，每次收集10分钟（600秒）内、间隔10秒（未直接体现，由
sadc内部处理）的6个样本。这会产生更密集的数据，但日志文件增长也更快。 - 第三行：每天23:53运行
sa2 -A，生成当天的汇总报告 (sarXX文件)。-A参数表示生成所有可能的报告（相当于-bBdFHqrRSuvwWy -I SUM -I XALL -m ALL -n ALL -u ALL -P ALL）。
你需要确保第一行和第三行是启用的（未被注释）。默认安装后通常就是启用的。
2. 启用并启动数据收集服务 (sadc)： 对于systemd系统，sysstat提供了一个服务，用于在系统启动时开始数据收集，并确保sadc守护进程运行。这个服务不是必须的，因为cron任务也能触发收集，但启用它可以确保更连贯的数据记录，特别是在系统启动初期的数据。
# 启用服务（开机自启） sudo systemctl enable sysstat # 启动服务 sudo systemctl start sysstat # 检查服务状态 sudo systemctl status sysstat3.4 验证配置与查看数据
配置完成后，等待至少一个cron周期（10分钟），然后进行检查。
# 1. 检查数据目录，应该能看到当天的 saXX 或 sarXX 文件 ls -lh /var/log/sa/ # 2. 查看今天的CPU历史数据，验证收集是否正常 sar -u -f /var/log/sa/sa$(date +%d) # 查看当天二进制文件中的CPU数据 # 或查看文本摘要报告 sar -u -f /var/log/sa/sar$(date +%d) # 查看当天的文本报告（如果已生成） # 3. 查看过去某一天的数据，例如查看5号的数据（如果5号在30天内） sar -u -f /var/log/sa/sa05如果能看到按时间序列排列的性能数据，说明自动收集和历史保存已经正常工作。
4. 高级配置与自定义技巧
4.1 调整数据收集粒度和内容
默认的每10分钟一次收集可能对某些精细化分析场景不够。你可以调整/etc/cron.d/sysstat中的sa1任务。
- 提高频率：将
*/10 * * * *改为*/5 * * * *可以每5分钟收集一次。注意，这会使数据文件体积增大一倍。 - 修改采样参数：
sa1后面的两个数字参数。例如，改为sa1 5 12表示每5分钟运行一次，每次收集时，以1秒为间隔采样12次（即过去1分钟内的数据）。但请注意，cron的最小粒度是1分钟，所以sa1的调用频率不能高于每分钟一次。更密集的采样需要直接配置sadc作为守护进程运行，这更复杂。
更常见的需求是增加收集的数据类型。回顾/etc/sysconfig/sysstat中的SADC_OPTIONS。例如：
SADC_OPTIONS="-S DISK,XDISK,INT"：收集基础磁盘、扩展磁盘和中断统计信息。SADC_OPTIONS="-S DISK,SNMP"：收集磁盘和SNMP网络设备统计。
修改后需要重启sysstat服务或等待下一个cron周期生效。
4.2 处理日志文件膨胀与归档策略
保留30天数据，尤其是如果收集频率高、数据类型多，/var/log/sa/目录可能会占用数GB甚至更多的磁盘空间。你需要监控这个目录的大小。
# 查看目录总大小 du -sh /var/log/sa/ # 查看各个文件大小 ls -lhS /var/log/sa/ | head -20应对策略：
- 压缩：
sysstat默认使用bzip2压缩旧文件。你可以考虑改用gzip（速度更快，压缩率稍低）或xz（压缩率最高，速度最慢）。在/etc/sysconfig/sysstat中修改ZIP变量即可。 - 调整
HISTORY：如果磁盘空间紧张，可以适当减少HISTORY天数，例如改为14。 - 自定义清理脚本：
sysstat的清理逻辑在/usr/lib64/sa/sa2（sa2脚本）和由它调用的sar命令中实现。它会在生成新报告时，自动删除超过HISTORY天数的旧sarXX文件，并通过一个名为sa2的机制清理saXX文件。这个机制通常是可靠的。如果你想更精细地控制（比如只保留周一的数据），可以编写自己的cron脚本来覆盖或补充默认行为，但这需要谨慎操作，避免破坏sar读取历史数据的连续性。
4.3 使用sar进行有效的性能分析
配置好了数据收集，关键在于如何利用这些数据。sar命令的强大之处在于其丰富的选项。
- 查看CPU使用率：
sar -u（整体），sar -P ALL（每颗CPU核心）。 - 查看内存和交换空间：
sar -r（内存使用），sar -S（交换空间），sar -B（分页统计）。 - 查看磁盘I/O：
sar -b（I/O和传输速率），sar -d -p（每个块设备详情）。 - 查看网络接口：
sar -n DEV（网络设备），sar -n EDEV（网络错误统计）。 - 查看进程和上下文切换：
sar -w（任务创建/上下文切换），sar -q（队列长度和负载）。 - 查看特定时间范围：
sar -u -s 10:00:00 -e 12:00:00查看上午10点到12点的CPU数据。 - 组合查看与导出：
sar -u -r -d -p -n DEV -f /var/log/sa/sa10可以一次性读取10号那天的多项数据。配合-o选项可以将查询结果导出为二进制文件，供后续sar -f读取。
一个非常实用的技巧是使用sadf命令（也是sysstat套件的一部分）将sar的二进制数据导出为CSV、XML等格式，便于用Excel、Grafana等工具进行可视化分析。
# 将某天的CPU数据导出为CSV sadf -d /var/log/sa/sa10 -- -u > cpu_usage_day10.csv5. 常见问题排查与运维心得
5.1 问题排查速查表
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
/var/log/sa/目录下没有saXX或sarXX文件 | 1.sysstat包未安装。2. cron服务未运行。3. /etc/cron.d/sysstat文件中的任务被注释或配置错误。4. sysstat服务未启动（影响启动初期数据）。 | 1.rpm -qa | grep sysstat确认安装。2. systemctl status crond检查cron服务状态。3. 检查 /etc/cron.d/sysstat文件内容，确保sa1和sa2任务行未被注释。4. 执行 sudo systemctl start sysstat并检查/var/log/sa/是否开始生成文件。 |
sar命令无法读取历史文件，提示“Cannot open /var/log/sa/saXX: No such file or directory” | 1. 日期不对，文件已被自动清理。 2. 文件路径或命名不符（如 sarXX和saXX混淆）。3. 文件权限问题。 | 1. 用ls /var/log/sa/确认目标日期的文件是否存在。2. 确认你使用的是 saXX（二进制数据文件）还是sarXX（文本报告文件）。sar -f通常读取saXX。3. 检查文件权限，应为 root所有，sa组可读。 |
| 历史数据没有保留30天，超过7天就被删除 | /etc/sysconfig/sysstat中的HISTORY参数未修改或修改未生效。 | 1. 确认cat /etc/sysconfig/sysstat | grep HISTORY输出为HISTORY=30。2. 清理操作由每日的 sa2任务触发。修改配置后，需要等到第二天sa2运行后，新的保留策略才会生效。可以手动执行一次sa2脚本（需谨慎）或等待一天观察。 |
/var/log/sa/目录磁盘空间占用增长过快 | 1. 数据收集频率过高。 2. 收集的数据类型过多 ( SADC_OPTIONS)。3. 压缩算法效率低或未压缩。 | 1. 评估并调整/etc/cron.d/sysstat中sa1的运行频率。2. 检查 /etc/sysconfig/sysstat中的SADC_OPTIONS，移除不必要的收集项。3. 将 ZIP改为gzip以获得更快的压缩速度，或定期手动归档并清理更早的数据。 |
sar查看实时数据正常，但查看历史数据时某项指标（如磁盘）为空 | 历史数据收集时未启用对应的收集选项。 | 检查历史数据文件生成时/etc/sysconfig/sysstat中的SADC_OPTIONS设置。例如，如果之前没有-S DISK，那么历史磁盘数据就是空的。修改配置后，新的数据会包含该指标，但旧数据无法补全。 |
5.2 实操心得与避坑指南
- 配置即代码，做好备份：在修改
/etc/sysconfig/sysstat或/etc/cron.d/sysstat之前，先备份原文件。一个错误的选项可能导致数据收集不全或服务异常。 - 理解“天”的定义：
HISTORY=30中的“天”，指的是文件日期。sysstat通过文件名sa[DD]中的DD来判断日期。清理脚本通常在生成新报告时，计算当前日期与文件日期的差值。确保系统时间（时区）准确无误，否则可能导致文件被过早或过晚清理。 - 监控存储空间：将
/var/log/sa/目录的大小纳入你的常规服务器监控（如Zabbix、Prometheus）。可以设置一个告警阈值，防止日志写满磁盘。 - 结合其他工具：
sar是趋势分析的王者，但对于实时报警，它并不擅长。通常将sar作为事后分析和容量规划的工具，实时监控则交给Prometheus+Node Exporter+Grafana或Zabbix等专业监控系统。两者互补，一个用于“诊断”，一个用于“预警”。 - 生成定期报告：可以利用
sa2脚本的思路，编写自己的cron任务，定期（如每周一早上）运行sar命令生成上周的性能摘要报告，并通过邮件发送给运维团队。例如：sar -u -r -b -q -f /var/log/sa/sa$(date -d "yesterday" +%d) | mail -s "Weekly System Performance Report" admin@example.com。 - 注意版本差异：不同版本（如
sysstatv10.x, v11.x, v12.x）的配置文件和工具选项可能有细微差别。部署前，最好在测试环境验证。使用sar -V查看版本号，并查阅对应版本的man手册。
