2. RHEL监控数据采集基础

在RHEL服务器上做监控，第一步不是装Agent，而是理解内核已经把哪些数据“摆在了桌面上”。Linux内核通过两个虚拟文件系统向用户态暴露运行状态：/proc和/sys。它们不占用磁盘空间，读取时由内核实时生成内容，因此是成本最低、最原始的数据源。绝大多数监控工具（包括sysstat、top、Prometheus node_exporter）本质上都是在解析这两个目录下的文件。

/proc：进程与内核统计的入口

/proc以“文件即接口”的方式呈现内核数据。与监控最相关的几个文件是：

  • /proc/stat：CPU时间片累计值，按user、nice、system、idle、iowait、irq、softirq、steal等维度分行给出。它是计算CPU使用率的基础。
  • /proc/meminfo：内存总量、可用量、缓存、缓冲区、Swap等，单位kB。
  • /proc/loadavg：1、5、15分钟平均负载，以及当前可运行进程数/总进程数。
  • /proc/diskstats：每块磁盘的读写次数、扇区数、耗时，是iostat的数据来源。
  • /proc/net/dev：每张网卡的收发字节、包数、错误与丢包计数。
  • /proc/<pid>/：单个进程的status、stat、io、fd等，用于进程级监控。

以CPU使用率为例，/proc/stat给出的是自开机以来的累计jiffies，必须取两次采样做差才能得到区间使用率。设两次采样间隔为Δt，则：

CPU% = 1 - Δ(idle + iowait) / Δ(total)
其中 total = user + nice + system + idle + iowait + irq + softirq + steal

这里有一个容易踩的坑：iowait是否计入“空闲”取决于监控口径。若关注CPU是否被IO拖住，应把iowait单独观察，而不是简单并入idle。

/sys：设备与内核子系统的结构化视图

/sys（sysfs）比/proc更规整，按设备、总线、类、模块组织，适合做设备级和参数级采集。例如：

  • /sys/class/net/eth0/statistics/：rx_bytes、tx_bytes、rx_dropped等，比解析/proc/net/dev更直接。
  • /sys/block/sda/stat：块设备IO统计。
  • /sys/class/thermal/thermal_zone*/temp：温度传感器读数。
  • /sys/fs/cgroup/：cgroup资源限制与用量，容器监控的关键路径。

与/proc相比，/sys的字段更稳定、语义更清晰，适合脚本化采集；而/proc中部分文件格式随内核版本略有差异，解析时需做兼容。

RHEL监控数据采集链路：从内核接口到可读指标 内核虚拟文件系统 /proc/stat · meminfo /proc/diskstats · net/dev /sys/class/net · block 采集工具与命令 top / vmstat（实时快照） iostat / mpstat（分设备/CPU） sar（历史回看） 数据落地 /var/log/sa/saDD 二进制日文件 sar -f 回放 采集频率与数据精度控制 高频采集（1~5s） 适合：突发毛刺、短时抖动 代价：CPU/IO开销上升 存储增长快 易被平均值掩盖 中频采集（10~60s） 适合：常规容量与趋势 sysstat默认10分钟 平衡精度与开销 生产环境常用 低频采集（5~15min） 适合：长期趋势、容量规划 开销极低 丢失瞬时峰值 需配合告警阈值

sysstat工具集：把瞬时值变成可回看的历史

sysstat是RHEL上最经典的性能数据采集套件，核心组件包括：

  • sar：系统活动报告，可实时也可读历史文件。
  • sadc：系统活动数据收集器，由cron或systemd timer定时调用。
  • sa1、sa2：封装脚本，分别负责“采集”和“生成日报”。
  • iostat、mpstat、pidstat：分别面向磁盘、CPU、进程的专项统计。

安装后需启用采集服务：

dnf install -y sysstat
systemctl enable --now sysstat
# 查看采集配置
grep -E '^HISTORY|^COMPRESSAFTER|^SA_DIR' /etc/sysconfig/sysstat

默认情况下，sysstat每10分钟采集一次，日志保存在/var/log/sa/下，文件名形如sa01（当月1日）。保留天数由HISTORY控制，默认28天。要回看昨天14:00到15:00的CPU：

sar -f /var/log/sa/sa$(date -d yesterday +%d) -s 14:00:00 -e 15:00:00 -u

若需要更细粒度，可修改/etc/cron.d/sysstat或对应的systemd timer，把采集间隔从10分钟缩短到1分钟。但要注意：间隔越短，/var/log/sa增长越快，需同步调整HISTORY或启用压缩。

top / vmstat / iostat / sar 的分工

这四个命令常被混用，实际各有侧重：

命令数据来源典型用途关键字段
top/proc/stat、/proc/<pid>实时看进程级CPU/内存%us、%sy、%wa、RES、S
vmstat/proc/stat、/proc/meminfo、/proc/vmstat看CPU、内存、IO、上下文切换的整体平衡r、b、si、so、bi、bo、cs
iostat/proc/diskstats看每块磁盘的吞吐、IOPS、await、%utilr/s、w/s、await、%util
sarsadc采集的历史文件事后回溯、趋势对比与vmstat/iostat字段对应

一个实用的排查顺序是：先用vmstat 1看整体是否有IO等待或内存回收压力，再用iostat -x 1定位具体磁盘，最后用pidstat -d 1或top找到消耗IO的进程。若问题发生在过去，则用sar回放对应时段。

采集频率与数据精度控制

采集频率不是越高越好。频率提高会带来三方面代价：采集进程自身消耗CPU；写入/var/log/sa增加磁盘IO；历史数据体积膨胀。同时，采样间隔本身决定了能捕捉到的最短事件——若一个毛刺只持续3秒，而采样间隔是10分钟，它几乎必然被平均掉。

因此需要按监控目标分层设置：

  • 容量与趋势类（磁盘使用率、内存增长）：5~15分钟一次即可。
  • 性能基线类（CPU、IO、网络）：1~5分钟一次，兼顾精度与开销。
  • 故障复现类（短时抖动、连接风暴）：临时用1秒间隔的vmstat或sar抓取，事后关闭。

另一个影响精度的是“平均口径”。sar默认输出的是区间平均值，若某分钟内前30秒CPU 100%、后30秒0%，平均值只有50%，看起来并不危险。要发现这种问题，需要缩短采样间隔，或结合%util、await等分布敏感指标一起判断。

在RHEL 8/9上，sysstat的采集由sysstat-collect.timer驱动，可用systemctl list-timers sysstat*确认下一次采集时间；修改间隔后需systemctl daemon-reload并重启timer。
不要直接把/proc/stat的累计值当作使用率上报。任何基于累计计数器的指标都必须做差分，并处理计数器回绕或重启归零的情况，否则会出现负值或尖峰。

掌握/proc与/sys的读取方式、sysstat的采集与回放机制，以及四个命令的分工和采样频率的取舍，就具备了在RHEL上自主构建监控数据源的能力。后续无论是接入Zabbix、Prometheus还是自研脚本，底层都绕不开这些接口和工具。

← 上一章 📖 返回目录 下一章 →