4. 操作系统与虚拟化层监控接口

要监控一台搭载 Intel Xeon 的服务器，最底层的观测点其实不在带外管理口，而在操作系统内部。CPU 的利用率、每核频率、缓存命中、内存带宽、温度、功耗、PCIe 错误，这些信息分散在 procfs、sysfs、性能计数器、IPMI/Redfish 以及虚拟化平台的管理接口中。本节按“从内核到虚拟化平台”的顺序，梳理这些接口各自能拿到什么、怎么取、取到的值如何判读。

一、procfs 与 sysfs：最轻量的状态入口

/proc 是内核暴露运行时状态的虚拟文件系统，读取成本极低，适合高频轮询。与 Xeon 监控最相关的几个文件：

• /proc/cpuinfo：列出逻辑处理器、型号、cpu MHz 当前频率、flags 特性位（如 avx512f、amx_bf16）。注意 cpu MHz 是瞬时采样值，不能直接当作稳态频率。
• /proc/stat：每 CPU 的累计 jiffies，字段依次为 user、nice、system、idle、iowait、irq、softirq、steal。两次采样求差即可算利用率，其中 steal 在虚拟机上代表被宿主机抢走的时间，是判断“虚机变慢是否因超分”的关键。
• /proc/meminfo：MemTotal、MemAvailable、Cached、HugePages_Total/Free。Xeon 上启用 1GB 大页时，HugePages_Free 归零往往先于内存耗尽出现。
• /proc/interrupts：每 CPU 的中断计数，用于确认网卡、NVMe 队列是否均匀分布到各核。

/sys/devices/system/cpu/ 下则是更结构化的信息：cpu0/cpufreq/scaling_cur_freq 给出当前频率（kHz），cpu0/topology/ 给出物理核、超线程与 NUMA 归属，cpu0/cache/index*/size 给出各级缓存容量。功耗与温度在 /sys/class/hwmon/ 或 /sys/class/powercap/intel-rapl/ 下，RAPL 的 energy_uj 是累计微焦耳，两次差值除以时间即为瓦特。

# 采样 1 秒，计算 package 功耗（示例）
E1=$(cat /sys/class/powercap/intel-rapl:0/energy_uj)
sleep 1
E2=$(cat /sys/class/powercap/intel-rapl:0/energy_uj)
echo "package power = $(( (E2-E1) / 1000000 )) W"

需要注意 energy_uj 会回绕，差值出现负数时应加上 max_energy_range_uj 再计算。

二、Linux perf：把 PMU 用起来

Xeon 每个核内置性能监控单元（PMU），perf 是访问它的标准工具。常用两类用法：

• perf stat：给出 IPC、分支预测失败率、LLC 命中率等宏观指标。例如 perf stat -e cycles,instructions,cache-misses,LLC-load-misses -p <pid> -- sleep 5。IPC 长期低于 0.5 通常意味着内存或锁竞争成为瓶颈。
• perf record/report：采样热点函数，定位到具体代码路径。

uncore（LLC、内存控制器、QPI/UPI）计数器不在核内，需要 perf stat -e uncore_imc_0/cas_count_read/ 这类事件，且通常要求 root 或调整 /proc/sys/kernel/perf_event_paranoid。虚拟机上 PMU 是否可用取决于 vCPU 是否透传 arch_perfmon，多数云主机默认关闭，此时应改用宿主机侧采集。

三、带外接口：ipmitool 与 Redfish

当操作系统已经卡死或宕机，带外接口是唯一通道。IPMI 通过 ipmitool 访问 BMC：

ipmitool sensor list | grep -Ei 'cpu|dimm|pwr'
ipmitool sdr type Temperature
ipmitool sel list | tail -20

可读到 CPU 温度、DIMM 温度、风扇转速、整机功耗与 SEL 事件日志。IPMI 的局限是协议老、明文、并发差，因此新一代平台转向 Redfish：基于 HTTPS 与 JSON，支持批量查询与订阅事件。

curl -k -u admin:pass https://bmc/redfish/v1/Systems/1/Processors/CPU1 \
  | jq '.Status, .ProcessorId, .Metrics'

Redfish 的 Thermal、Power、Processors、Memory 资源可直接映射到监控系统，且支持 EventService 推送，比轮询 SEL 更及时。

四、虚拟化层：libvirt、vCenter/ESXi 与 Hyper-V

在虚拟化环境中，Xeon 的资源被切分给多个虚机，监控必须同时看宿主机和虚机两侧。

• libvirt/KVM：virsh domstats <vm> 给出 vCPU 时间、内存、块设备与网络统计；virsh cpu-stats 给出每 vCPU 占用。宿主机侧用 virsh nodecpustats 与 virsh node-memory-total。NUMA 绑核情况可用 virsh numatune 与 virsh vcpupin 核对。
• vCenter/ESXi：通过 vSphere API 或 esxcli 获取。关键指标包括 cpu.usage.average、cpu.ready.summation（就绪等待，等价于 KVM 的 steal）、mem.vmmemctl.average（气球回收）、cpu.coreUtilization。ESXi 主机侧用 esxcli hardware cpu global get 查看物理核与超线程状态。
• Hyper-V：Get-VM 配合 Get-VMProcessor、Get-VMMemory，性能计数器 \Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time 反映物理核占用，\Hyper-V Hypervisor Root Virtual Processor(*)\% Guest Run Time 反映虚机消耗。

虚拟化层最容易踩的坑是“指标口径不一致”：虚机内看到的 CPU 利用率是相对 vCPU 数的，宿主机看到的是相对物理核的。若一台 8 vCPU 虚机跑满，在 32 物理核宿主机上只占 25%，但虚机内显示 100%。做容量运营时必须统一到物理核口径，否则会严重低估超分率。

五、接口选择与组合策略

这些接口不是互相替代，而是分层互补。一个可落地的组合是：

把上述接口串起来，就形成了一条从硅片到管理平台的完整观测链：PMU 与传感器提供原始信号，procfs/sysfs/perf 在内核侧暴露，libvirt 与 vCenter 在虚拟化侧聚合，IPMI/Redfish 在带外兜底。理解每一层的口径差异，比记住命令本身更重要。