4. 部署EPYC监控采集栈

监控采集栈的部署不是把几个 exporter 装上去就结束，而是一条从硬件传感器到 Prometheus 时序库的完整链路。对 AMD EPYC 平台而言，这条链路上至少有三类数据源：操作系统可见的通用资源指标、EPYC 处理器特有的 RAS/APML/EDC 等硬件指标，以及 BMC 侧带外的功耗、温度和事件日志。三类数据源采集方式不同、暴露格式不同、更新频率也不同，必须分别规划采集器，再统一汇入 Prometheus。

本节以一台双路 EPYC 9004 服务器（示例主机名 epyc-node-01，BMC 地址 10.20.30.40）为对象，完成 node_exporter、AMD EPYC 专用 exporter、BMC exporter 以及自定义采集脚本的部署，并验证指标真正入库。

一、先规划端口与采集职责，避免冲突

部署前先确定每个采集器监听端口和采集职责，避免端口冲突和指标重复。示例规划如下：node_exporter 监听 9100，负责 CPU、内存、磁盘、网络、NUMA 拓扑等通用指标；AMD EPYC 专用 exporter 监听 9250，负责 EDC、APML 功耗、RAS 可纠正/不可纠正错误计数；BMC exporter 监听 9610，负责带外功耗、进风口温度、风扇转速和 SEL 事件；自定义脚本通过 textfile collector 输出到 /var/lib/node_exporter/textfile/，由 node_exporter 在 9100 上以 epyc_custom_* 前缀暴露。

二、部署 node_exporter 并开启 textfile collector

node_exporter 是整条链路的底座。下载二进制后以 systemd 方式运行，关键是开启 textfile collector，为自定义脚本预留输出通道：

# 下载并安装
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xzf node_exporter-1.8.2.linux-amd64.tar.gz
sudo cp node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/

# systemd 单元关键参数
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=:9100 \
  --collector.textfile.directory=/var/lib/node_exporter/textfile \
  --collector.cpu \
  --collector.meminfo_numa

sudo systemctl enable --now node_exporter
curl -s http://localhost:9100/metrics | grep node_cpu_seconds_total | head

验证要点：node_cpu_seconds_total 应出现且带 cpu 标签；node_memory_MemAvailable_bytes 有值；若启用了 NUMA collector，应能看到 node_meminfo_numa_* 系列。这些指标是后续容量基线的基础。

三、部署 AMD EPYC 专用 exporter

EPYC 的硬件级指标无法从通用内核接口完整获取，需要专用 exporter 读取 APML 或通过 rasdaemon、amd_energy 等接口暴露。以社区常用的 AMD exporter 为例，它通过 /dev/cpu/*/msr 和 APML 读取 EDC（Electrical Design Current）余量、封装功耗和 RAS 错误计数：

# 加载 MSR 模块并授权
sudo modprobe msr
sudo setcap cap_sys_rawio+ep /usr/local/bin/amd_exporter

# 启动，监听 9250
/usr/local/bin/amd_exporter --web.listen-address=:9250 \
  --apml.enable --msr.enable

curl -s http://localhost:9250/metrics | grep -E 'epyc_edc|epyc_ras'

示例输出中应关注 epyc_edc_current_limit、epyc_edc_current_actual 和 epyc_ras_ce_total、epyc_ras_ue_total。EDC 实际值持续接近限值，说明该路 CPU 电流接近设计上限，是容量告警的重要信号；UE 计数非零则需立即排查内存或互联链路。

四、部署 BMC exporter 获取带外数据

BMC exporter 通过 IPMI 或 Redfish 采集带外指标，即使操作系统宕机也能持续上报。以 Redfish 方式为例，配置 BMC 凭据后启动：

export BMC_HOST=10.20.30.40
export BMC_USER=monitor
export BMC_PASS='******'

/usr/local/bin/bmc_exporter \
  --web.listen-address=:9610 \
  --redfish.system /redfish/v1/Systems/1 \
  --redfish.chassis /redfish/v1/Chassis/1

curl -s http://localhost:9610/metrics | grep -E 'bmc_power|bmc_temp'

关键指标包括 bmc_power_watts、bmc_inlet_temp_celsius、bmc_fan_rpm。带外功耗与 EPYC exporter 的封装功耗可交叉验证：若两者差异超过 15%，通常说明传感器口径不同或存在采集延迟，需要在告警规则中设置合理阈值。

五、自定义脚本补齐业务侧指标

有些指标既不在通用接口也不在硬件 exporter 中，例如特定 NUMA 节点的内存带宽占用、GPU 与 EPYC 的 PCIe 链路状态。这类指标用自定义脚本采集，输出为 Prometheus 文本格式，写入 textfile 目录：

#!/bin/bash
# /usr/local/bin/epyc_custom.sh
OUT=/var/lib/node_exporter/textfile/epyc_custom.prom
TMP=$(mktemp)
echo "# HELP epyc_numa_bandwidth_gbps NUMA 节点内存带宽" > $TMP
echo "# TYPE epyc_numa_bandwidth_gbps gauge" >> $TMP
for n in 0 1; do
  bw=$(numactl --hardware | awk -v n=$n '/node '$n' size/ {print $4}')
  echo "epyc_numa_bandwidth_gbps{node=\"$n\"} $bw" >> $TMP
done
mv $TMP $OUT

# 每 30 秒执行一次
echo "*/1 * * * * root /usr/local/bin/epyc_custom.sh" > /etc/cron.d/epyc_custom

脚本必须原子写入（先写临时文件再 mv），否则 node_exporter 可能读到半截文件导致解析失败。执行后通过 curl -s localhost:9100/metrics | grep epyc_custom 确认指标已出现。

六、Prometheus 抓取配置与入库验证

四类采集器就绪后，在 Prometheus 的 scrape_configs 中统一纳管：

scrape_configs:
  - job_name: 'epyc-node'
    static_configs:
      - targets: ['epyc-node-01:9100']
  - job_name: 'epyc-amd'
    static_configs:
      - targets: ['epyc-node-01:9250']
  - job_name: 'epyc-bmc'
    static_configs:
      - targets: ['epyc-node-01:9610']

重载配置后，在 Prometheus 的 /targets 页面确认三个 job 均为 UP。随后用查询验证入库：epyc_edc_current_actual 应返回两条时间序列（对应两个 socket），bmc_power_watts 应有连续采样点。若某个 target 为 DOWN，按“端口是否监听 → 防火墙是否放行 → exporter 日志是否报错 → 凭据是否正确”的顺序排查。

七、部署完成后的检查清单

至此，从裸机传感器到 Prometheus 时序库的端到端链路已经打通。后续的告警规则、容量基线和运营看板，都建立在这条链路稳定采集的基础之上。