3. iLO管理接口与监控能力

HPE ProLiant 的带外管理核心是 iLO（Integrated Lights-Out）。它独立于主机操作系统运行，只要服务器接入管理网并供电，就能提供硬件状态、健康事件、日志与远程控制能力。对监控与容量运营而言，关键不是“能不能登录 iLO”，而是理解 iLO 对外暴露的几类接口分别适合采集什么数据、以什么方式推送或拉取、以及配置时最容易踩的坑。本节围绕 Redfish、SNMP、SMTP、Syslog 和 iLO Federation 五条通道展开。

一、五条监控通道的定位差异

这五类接口并非互相替代，而是覆盖不同的采集模式与消费端：

• Redfish：基于 HTTPS 的 RESTful API，返回结构化 JSON，适合现代监控平台做主动轮询与资源建模，是获取详细硬件清单、传感器、固件版本、电源与散热数据的首选。
• SNMP：传统网管协议，iLO 提供 SNMP v1/v2c/v3 代理与 Trap 主动上报，适合已有 Zabbix、SolarWinds 等 SNMP 体系的场景。
• SMTP：iLO 自身作为邮件客户端，把告警以邮件形式发出，适合无集中监控平台时的人工值守。
• Syslog：iLO 将 IML（Integrated Management Log）事件以 syslog 格式转发到日志服务器，适合集中审计与关联分析。
• iLO Federation：多台 iLO 组成组，实现组内统一查看与批量操作，适合规模化机群的集中管理。

理解这五者的关系，可以用下面的信号链来把握：iLO 内部的事件与传感器数据是“源”，Redfish/SNMP 是“拉取或 Trap 推送”的采集面，Syslog/SMTP 是“主动外发”的通知面，Federation 则是“多节点聚合”的管理面。

二、Redfish：结构化采集的主力

Redfish 使用标准资源树，入口通常是 https://<iLO_IP>/redfish/v1/。常用路径包括 /redfish/v1/Systems/1（主机与处理器、内存概要）、/redfish/v1/Chassis/1/Thermal（温度与风扇）、/redfish/v1/Chassis/1/Power（电源与功耗）、/redfish/v1/Managers/1（iLO 自身信息）。采集前需在 iLO 中创建专用只读账户，并确认 Redfish 服务已启用。

一个典型的采集动作是先用会话认证，再读取资源。示例（参数为教学示例，非实测结果）：

# 1) 建立会话，获取 X-Auth-Token
curl -k -X POST https://192.168.10.21/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName":"monitor_ro","Password":"<password>"}'

# 2) 用返回的 Token 读取电源与功耗
curl -k -H "X-Auth-Token: <token>" \
  https://192.168.10.21/redfish/v1/Chassis/1/Power

# 3) 读取温度传感器
curl -k -H "X-Auth-Token: <token>" \
  https://192.168.10.21/redfish/v1/Chassis/1/Thermal

返回的 JSON 中，PowerConsumedWatts 表示当前功耗，PowerCapacityWatts 表示电源容量，二者之比可用于容量水位判断；Temperatures[].ReadingCelsius 与 UpperThresholdCritical 对比可判断散热风险。配置要点：优先使用会话而非每次基本认证，减少认证开销；轮询间隔建议 60～300 秒，过密会加重 iLO 负担；对返回的 @odata.id 做递归遍历可自动发现全部资源。

三、SNMP：兼容既有网管体系

在 iLO 的“Management → SNMP”中启用代理，设置 Read Community（v1/v2c）或 v3 用户与认证加密参数，并配置 Trap 目标地址。iLO 使用 HPE 的 cpqHe、cpqRack 等 MIB，需将 MIB 文件导入网管平台才能解析 OID 含义。SNMP 适合采集电源状态、风扇状态、温度阈值、IML 事件计数等离散量；Trap 则在事件发生时主动上报，适合做即时告警。注意 v2c 的 community 明文传输，生产环境建议启用 v3 的 authPriv。

四、Syslog 与 SMTP：主动外发的通知面

Syslog 配置位于 iLO 的“Management → Syslog”，填写日志服务器地址与端口（默认 514），并选择转发级别。iLO 会把 IML 中的事件（如电源故障、风扇降级、内存可纠正错误超阈值）以 syslog 消息发出，便于在 SIEM 中与主机日志关联。SMTP 则在“Management → AlertMail”中配置发件服务器、端口、发件地址与收件人，并可按事件类别选择触发条件。两者都属于“iLO 主动推送”，不依赖外部轮询，但需要保证 iLO 能访问对应服务器，且注意邮件网关对发件域的反垃圾策略。

五、iLO Federation：规模化机群的聚合面

Federation 让多台 iLO 加入同一组，组内成员可互相查询状态、批量执行电源操作、统一查看固件版本。配置时需保证组名、组密钥一致，且各 iLO 之间网络可达。它本身不是数据采集协议，而是管理聚合层：可以在 Federation 视图中快速发现某组内哪台服务器温度偏高、哪台固件落后，再回到 Redfish 或 SNMP 做细粒度采集。对容量运营而言，Federation 适合做“机群级巡检”，Redfish 适合做“单机级指标采集”。

六、采集通道选择速查