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/sysstatCentOS/RHEL或/etc/default/sysstatUbuntu/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. HISTORY28 # 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. ZIPbzip2HISTORY28这是控制历史数据保留天数的关键参数注意注释里明确说了如果值大于28日志文件会按月分目录存储。默认28天已经接近30天但为了确保整整30天我们通常就设置为30。SADC_OPTIONS-S DISKsadc的选项。-S指定要收集的数据类型DISK表示收集磁盘统计信息。你可以根据需要添加其他选项如-S XDISK收集扩展磁盘统计-S POWER收集电源管理统计等具体见man sadc。ZIPbzip2指定用于压缩旧日志文件的程序。bzip2压缩率高但较慢也可以改为gzip或xz。3.2 关键配置修改数据保留策略我们的目标是保留30天数据。直接修改/etc/sysconfig/sysstat文件sudo vi /etc/sysconfig/sysstat将HISTORY参数的值修改为30HISTORY30保存并退出。这个修改意味着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/sa2sa2脚本和由它调用的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/Osar -bI/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输出为HISTORY30。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之前先备份原文件。一个错误的选项可能导致数据收集不全或服务异常。理解“天”的定义HISTORY30中的“天”指的是文件日期。sysstat通过文件名sa[DD]中的DD来判断日期。清理脚本通常在生成新报告时计算当前日期与文件日期的差值。确保系统时间时区准确无误否则可能导致文件被过早或过晚清理。监控存储空间将/var/log/sa/目录的大小纳入你的常规服务器监控如Zabbix、Prometheus。可以设置一个告警阈值防止日志写满磁盘。结合其他工具sar是趋势分析的王者但对于实时报警它并不擅长。通常将sar作为事后分析和容量规划的工具实时监控则交给PrometheusNode ExporterGrafana或Zabbix等专业监控系统。两者互补一个用于“诊断”一个用于“预警”。生成定期报告可以利用sa2脚本的思路编写自己的cron任务定期如每周一早上运行sar命令生成上周的性能摘要报告并通过邮件发送给运维团队。例如sar -u -r -b -q -f /var/log/sa/sa$(date -d yesterday %d) | mail -s Weekly System Performance Report adminexample.com。注意版本差异不同版本如sysstatv10.x, v11.x, v12.x的配置文件和工具选项可能有细微差别。部署前最好在测试环境验证。使用sar -V查看版本号并查阅对应版本的man手册。