📚 课程目录第3章服务器功耗测量与数据采集

3. 服务器功耗测量与数据采集

要优化机房资源，第一步不是“省电”，而是“看清电”。HPE ProLiant 服务器提供了从带外管理到标准 API 的多层功耗数据通道，理解每条通道的数据来源、采样粒度和适用场景，才能构建可信的功耗曲线。本节围绕 iLO、HPE Power Advisor、Redfish API 与功率封顶传感器四条主线，说明单机与机柜功耗的实测方法。

一、四条数据通道的定位

iLO 带外管理是功耗数据的“根”。即使操作系统未启动、服务器处于关机或待机状态，iLO 仍持续工作，通过电源管理总线读取电源模块（PSU）的输入功率、输出电压电流、进风口温度等。iLO 的功耗读数通常以约 1 秒为周期刷新，适合做长期趋势记录和告警阈值判断。

HPE Power Advisor 是规划阶段的估算工具，它基于服务器型号、CPU、内存、硬盘、PCIe 卡等配置清单，结合负载假设给出功耗估算区间。它不连接真实硬件，因此适合在采购或上架前做容量规划，但不能替代实测。

Redfish API 是 DMTF 标准的管理接口，HPE iLO 5/6 均提供 Redfish 实现。通过 /redfish/v1/Chassis/1/Power 等资源，可以程序化读取 PowerConsumedWatts、PowerMetrics、PowerLimit 等字段，是把功耗数据接入监控平台（如 Prometheus、Zabbix）的首选方式。

功率封顶传感器（Power Capping）是 iLO 中的可写控制点。它读取当前功率并允许设置上限，当功率接近阈值时，iLO 通过 CPU 降频、内存限速等手段压低功耗。它既是数据源，也是执行器。

二、用 Redfish 采集单机功耗

Redfish 采集的核心是认证与资源路径。HPE iLO 支持 Basic Auth 和 Session 认证，批量采集建议先创建会话再复用。以下示例展示读取功率资源的关键字段：

# 创建会话（示例）
curl -k -X POST https://192.168.1.20/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName":"admin","Password":"********"}'

# 读取功率资源
curl -k -H "X-Auth-Token: <token>" \
  https://192.168.1.20/redfish/v1/Chassis/1/Power

# 返回片段（示例）
{
  "PowerConsumedWatts": 412,
  "PowerMetrics": {
    "MinConsumedWatts": 180,
    "MaxConsumedWatts": 520,
    "AverageConsumedWatts": 395
  },
  "PowerLimit": {
    "LimitInWatts": 600,
    "LimitException": "LogEventOnly"
  }
}

其中 PowerConsumedWatts 是瞬时值，PowerMetrics 是 iLO 维护的统计窗口值。若要做曲线，应周期性拉取瞬时值并写入时序库，而不是只记录平均值。轮询间隔建议 5～15 秒：过密会增加 iLO 负担，过疏会丢失负载突变的细节。

三、功率封顶传感器的读与写

功率封顶是“测量 + 控制”的闭环。读取时关注三个量：当前功率、封顶阈值、封顶状态。写入时通过 Redfish 的 PATCH 设置 LimitInWatts，并选择 LimitException 的行为——是仅记录日志，还是触发降频甚至关机。

实际配置中，阈值不能拍脑袋。建议先采集 24 小时稳态峰值，例如某台 DL380 Gen10 在业务高峰达到 520 W，则封顶阈值可设为 580～600 W，留出 10%～15% 余量。若设得过低，CPU 会频繁进入降频状态，表现为功率曲线被“削平”但业务响应变慢；若设得过高，则失去保护意义。

四、从单机到机柜的实测方法

单机功耗曲线只能回答“这台机器用了多少电”，机柜功耗还要回答“电从哪来、余量还有多少”。机柜级测量通常有两种方式：一是通过机柜 PDU 读取总功率，二是把柜内各节点 Redfish 数据求和。两者应交叉验证：若 PDU 总功率明显大于节点之和，差额来自交换机、存储、风扇等未纳入采集的设备，规划时不能忽略。

一个可复用的实测流程如下：

确认每台服务器的 iLO 已启用 Redfish，且管理口可达；记录 IP、账号、机柜位置。
用脚本按 10 秒间隔采集 PowerConsumedWatts，同时记录时间戳与主机名。
在 PDU 侧同步采集机柜总功率，采样间隔与服务器侧对齐。
持续采集至少一个完整业务周期（如 24 小时或 7 天），覆盖高峰与低谷。
将数据写入时序库，绘制单机曲线与机柜叠加曲线，标注峰值、均值与波动区间。
用 Power Advisor 按实际配置估算，与实测峰值对比，偏差超过 20% 时核查配置清单是否遗漏部件。

若机房已有 Prometheus，可使用 redfish_exporter 将 iLO 的 Power 资源暴露为指标，配合 Grafana 直接出图，避免自建采集脚本的维护成本。

五、结果判读与常见偏差

拿到曲线后，重点看三件事：峰值是否接近封顶阈值、均值是否与规划容量匹配、波动是否与业务负载同步。若功率曲线长期贴着封顶线运行，说明阈值设置过紧或散热余量不足；若曲线几乎是一条直线，则要检查采集是否只取到了平均值，丢失了瞬时波动。

常见偏差包括：iLO 读数与 PDU 读数因采样时刻不同产生瞬时差异；多电源服务器只读到一个 PSU 的功率；以及 Redfish 会话超时导致数据断点。排查时先确认采集脚本是否处理了会话续期，再核对 PSU 冗余模式是否影响功率分配。

功率封顶是保护手段，不是节能手段。把阈值设得过低会以性能换功耗，可能触发业务超时。任何封顶调整都应在业务低峰期进行，并保留回退配置。

掌握这四条通道后，单机与机柜的功耗就不再是黑盒。iLO 提供底层读数，Redfish 提供程序化入口，Power Advisor 提供规划参照，功率封顶传感器提供控制边界。四者配合，才能得到既准确又可执行的功耗曲线，为后续的机房资源优化打下数据基础。