2. PowerEdge硬件监控对象梳理
要对一台 PowerEdge 服务器做有效的监控告警与容量运营，第一步不是急着配阈值，而是把"到底有哪些东西需要被监控"梳理清楚。PowerEdge 的硬件监控对象可以按物理层级和功能角色分成若干类：机箱与主板是承载与总线基础，CPU、内存、PCIe 是计算与扩展核心，风扇、电源是散热与供电保障，RAID 控制器、物理磁盘、虚拟磁盘构成存储链路，网卡与 GPU 则是网络与加速部件。每一类对象都有各自的健康指标，也都有各自的告警来源，理解这种"对象—指标—来源"的对应关系，是后续配置告警策略的前提。
机箱与主板：承载与总线基础
机箱（Chassis）层面的监控对象包括机箱入侵状态、机箱温度、前面板 LED 状态以及整体电源状态。机箱入侵开关（Intrusion）一旦被触发，iDRAC 会记录一条事件，这类告警通常来自 iDRAC 的机箱传感器。机箱温度则通过进风口温度（Inlet Temperature）传感器采集，是判断散热是否正常的第一手数据。
主板（System Board）层面关注的是主板温度传感器、CMOS 电池电压、主板上的电压调节模块（VRM）状态。主板温度过高往往意味着风道受阻或风扇异常，而 CMOS 电池电压偏低会导致 BIOS 时间丢失、配置无法保存。这些指标主要由 iDRAC 通过内部传感器总线采集，告警来源是 iDRAC 的传感器事件日志（SEL）。
CPU、内存与 PCIe：计算与扩展核心
CPU 的监控指标包括处理器温度、CPU 功耗、CPU 状态（是否被禁用或降频）、以及 CPU 相关的机器检查异常（MCA）。CPU 温度过高会触发降频保护，严重时触发热关机。CPU 告警来源有两类：一是 iDRAC 采集的温度与功耗传感器，二是 BIOS/操作系统层面的 MCA 日志，后者通常通过 OMSA 或 iDRAC 的 Lifecycle Log 呈现。
内存（DIMM）的监控重点是内存模块的健康状态、可纠正错误（CE）与不可纠正错误（UCE）计数、以及内存温度。可纠正错误持续增长是内存即将失效的早期信号，不可纠正错误则直接导致系统崩溃。内存告警主要来自 iDRAC 的内存传感器和 BIOS 的 POST 事件，部分高级错误通过 EDAC 在操作系统侧暴露。
PCIe 设备（包括插槽和板载设备）的监控对象是链路状态、链路宽度与速率、以及 PCIe 错误计数。链路降速或降宽会直接影响扩展卡性能，而 PCIe 可纠正/不可纠正错误则反映链路质量。这类告警来源是 iDRAC 的 PCIe 传感器和系统日志。
风扇与电源：散热与供电保障
风扇（Fan）的监控指标是转速（RPM）、风扇状态（正常/故障/缺失）以及风扇冗余状态。转速异常偏低或风扇缺失会立即触发告警，冗余风扇失效则属于降级告警。风扇告警来源是 iDRAC 的风扇传感器，通常以 RPM 阈值和状态位两种方式呈现。
电源（PSU）的监控对象包括电源状态（在线/离线/故障）、输入电压、输出电压、输出功率、电源冗余状态以及电源固件版本。电源冗余丢失（一路 PSU 故障）是常见告警，而输入电压异常则可能反映机房供电问题。电源告警来源是 iDRAC 的电源传感器和 PSU 自身的 PMBus 通信。
RAID 控制器、物理磁盘与虚拟磁盘：存储链路
RAID 控制器（PERC）的监控指标包括控制器状态、固件版本、电池/电容状态（BBU/Cache Vault）、以及控制器温度。电池或电容失效会导致写缓存策略降级，进而影响写性能。控制器告警来源是 iDRAC 的存储传感器和 PERC 控制器自身的事件日志。
物理磁盘（Physical Disk）的监控重点是磁盘状态（Online/Offline/Failed/Rebuild）、SMART 健康状态、介质错误计数、以及磁盘温度。SMART 预测性故障是提前更换磁盘的关键依据。物理磁盘告警来源是 PERC 控制器上报的磁盘事件，经 iDRAC 的存储子系统呈现。
虚拟磁盘（Virtual Disk）的监控对象是虚拟磁盘状态（Optimal/Degraded/Failed）、RAID 级别、以及后台初始化/重建进度。虚拟磁盘降级意味着冗余已丢失，必须尽快处理。虚拟磁盘告警同样来自 PERC 控制器，通过 iDRAC 的存储事件日志暴露。
网卡与 GPU：网络与加速部件
网卡（NIC）的监控指标包括链路状态（Up/Down）、链路速率、端口错误计数、以及网卡温度。链路频繁 Up/Down 抖动往往意味着光模块或线缆问题。网卡告警来源是 iDRAC 的网络传感器和网卡自身的固件日志，部分信息通过操作系统侧的 ethtool 或 SNMP 获取。
GPU 的监控对象包括 GPU 温度、功耗、显存使用率、ECC 错误计数以及 GPU 健康状态。GPU 温度过高会触发降频，ECC 错误则影响计算可靠性。GPU 告警来源是 iDRAC 的 GPU 传感器（对支持的型号）以及 GPU 厂商的管理工具（如 NVIDIA DCGM）。
从对象到告警：如何组织监控策略
梳理清楚对象之后，实际配置监控时建议按"对象分类—指标分级—来源确认—阈值设定"四步走。以物理磁盘为例：对象是 PERC 下的所有物理磁盘；指标分级上，SMART 预测性故障属于警告级，磁盘 Failed 属于严重级，Rebuild 进行中属于信息级；来源确认要明确是 PERC 事件还是 iDRAC 存储传感器；阈值设定则要结合业务容忍度，比如 RAID5 中允许一块盘故障，那么单盘 Failed 应触发严重告警，而 Rebuild 进度只需记录。
再以电源为例：PSU 冗余丢失（一路故障）应触发严重告警，因为此时已无冗余；输入电压波动属于警告级，需要观察是否持续；PSU 固件版本不一致属于信息级，可在维护窗口统一升级。这种分级方式能让告警既有优先级，又不会因为过度敏感而淹没运维人员。
racadm getsensorinfo 或 Redfish 接口枚举当前机型实际存在的传感器，再逐项设定，避免对不存在的对象配置无效阈值。
告警来源的差异与互补
需要特别注意的是，同一对象可能有多个告警来源，它们之间是互补而非替代关系。以 CPU 为例，iDRAC 提供温度与功耗传感器数据，BIOS 提供 POST 阶段的 MCA 记录，操作系统侧则通过 EDAC 或 mcelog 暴露运行时的机器检查异常。只监控 iDRAC 会漏掉操作系统层面的错误，只监控操作系统则看不到带外温度与功耗。因此，完整的监控策略应当把带内与带外来源结合起来。
存储链路同样如此：PERC 控制器的事件日志最详细，但需要 iDRAC 或 OMSA 转发；虚拟磁盘状态在 iDRAC 存储页面可见，但重建进度等动态信息更适合通过 Redfish 定期轮询。网卡方面，iDRAC 能看到链路状态和部分错误计数，但更细的端口统计需要操作系统侧的 ethtool 或 SNMP 采集。