3. XClarity Administrator与XClarity Controller监控体系

Lenovo ThinkSystem 的带外监控由两个核心组件协同完成：XClarity Controller（XCC）是每台服务器主板上的管理控制器，负责采集本机硬件状态、提供 Redfish/SNMP 接口并生成事件；XClarity Administrator（LXCA）是集中管理平台，负责批量纳管设备、汇聚事件、统一呈现视图并把告警转发到外部系统。理解两者的分工与数据流向，是搭建可运营监控体系的前提。

一、XCC 与 LXCA 的职责边界

XCC 是监控数据的源头。它独立于操作系统运行，即使主机断电（只要管理口有电）仍可工作，采集的典型对象包括：CPU/内存/PCIe 温度、风扇转速、电源模块状态、电压、硬盘与 RAID 状态、BIOS/固件版本、开机自检事件、机箱入侵检测等。XCC 通过 Redfish（HTTPS 443）、SNMP v3、Syslog 等方式对外暴露数据。

LXCA 是监控数据的汇聚与分发层。它不直接读取传感器，而是通过 XCC 的接口周期性拉取清单与状态，并接收 XCC 主动推送的事件。LXCA 的价值在于：一次纳管数百台设备、跨机型统一视图、事件去重与关联、告警转发到邮件/Syslog/SNMP 目标/Webhook。

二、设备纳管：从发现到受管

纳管是监控体系的起点。LXCA 支持三种发现方式：手动添加单个 IP、按 IP 范围扫描、导入 CSV 批量发现。发现时 LXCA 会尝试用配置的凭据（XCC 用户名/密码，或服务账户）登录目标 XCC，读取机型、序列号、UUID、固件版本。

纳管状态通常经历：已发现（Discovered）→ 正在管理（Managing）→ 受管（Managed）。若停留在“已发现”，常见原因是凭据错误、XCC 网络不可达、XCC 固件过旧不支持 Redfish 接口、或管理口 IP 冲突。建议在纳管前统一 XCC 固件版本，并确认 LXCA 到 XCC 管理网段的 443 端口可达。

教学示例：假设一台 SR650 的 XCC 管理 IP 为 10.20.30.41，在 LXCA 中按 IP 范围 10.20.30.40–10.20.30.60 扫描，使用服务账户 lxca-svc 纳管。纳管成功后，LXCA 的“受管设备”列表应显示该机型的序列号与固件版本，且状态为绿色“受管”。

三、事件订阅：让 XCC 主动推送

仅靠轮询会延迟告警。LXCA 纳管设备后，会向 XCC 注册事件订阅（Event Subscription），即通过 Redfish 的 EventService 在 XCC 上登记一个接收地址（LXCA 的事件接收端点）。此后 XCC 检测到硬件事件时，会主动 POST 到该地址，实现秒级上报。

订阅的关键参数包括：目标 URL、事件类型（如 StatusChange、ResourceUpdated、Alert）、订阅有效期。若订阅失效（例如 LXCA 地址变更、证书过期），XCC 会退回仅本地记录，LXCA 只能靠轮询发现变化，告警延迟明显增大。因此应定期检查订阅状态。

四、告警转发：把事件送到该去的地方

LXCA 收到事件后，按转发规则分发。常见目标有四类：

• 邮件：适合人工值守，可配置收件人组与严重级别过滤。
• Syslog：转发到 SIEM 或日志平台，便于集中检索与合规留存。
• SNMP Trap：转发到 Zabbix、SolarWinds 等网管平台，复用既有告警流程。
• Webhook：转发到自建平台或 IM 机器人，实现自动化响应。

转发规则应包含过滤条件：事件严重级别（Critical/Warning/Info）、事件类别（电源、温度、存储、固件）、设备分组。避免“全量转发”导致告警风暴。建议 Critical 立即转发，Warning 聚合后转发，Info 仅入库不转发。

五、集中视图与基础配置实战

LXCA 的集中视图包括：受管设备总览、事件日志、硬件清单、固件合规、健康状态仪表盘。运维人员应重点关注“未处理事件”与“健康状态非绿”的设备。

基础配置建议按以下顺序落地：

1. 配置 LXCA 自身网络与时间源（NTP），确保事件时间戳准确。
2. 创建服务账户并统一 XCC 凭据，完成批量纳管。
3. 验证事件订阅状态为“活动”。
4. 配置至少一个转发目标（如 Syslog），并发送测试事件验证链路。
5. 建立设备分组（按机房、业务、机型），便于分级告警。

验证方法：在 XCC 上模拟或触发一个可恢复事件（如临时拔掉冗余电源），观察 LXCA 事件日志是否在数秒内出现该事件，并确认 Syslog 目标是否收到对应记录。若 LXCA 有记录但 Syslog 无记录，问题在转发规则；若两者都无，问题在订阅或 XCC 事件生成。

六、常见问题与判断依据

实践中三类问题最常见。第一，设备无法纳管：检查 XCC 管理口连通性、凭据、固件版本；若 XCC 固件过旧，Redfish 接口可能不完整，需先升级。第二，事件延迟或缺失：检查事件订阅是否仍为“活动”，LXCA 地址或证书是否变更。第三，转发失败：检查目标端口、Syslog 格式、SNMP community/版本、Webhook 可达性，并确认转发规则未被误过滤。

建议把“订阅状态、转发目标连通性、事件日志增长率”纳入日常巡检。只有源头（XCC）采集正常、汇聚（LXCA）订阅有效、出口（转发）链路通畅，监控体系才真正可用。