TG咨询服务器出现故障前，往往不会先表现为“整机宕机”。风扇转速升高、磁盘介质错误增加、内存校验错误累积，可能已经说明硬件正在恶化。因此，服务器硬件资源监控的重点不是把每个指标都设置一个阈值，而是判断多个信号是否指向同一风险，并让告警在合适的时间升级。
先确定监控对象：状态、健康度和趋势都要采集
硬件监控至少应覆盖三类数据。第一类是实时状态，包括处理器温度、主板温度、风扇转速、电源输入状态和机箱告警灯。第二类是健康度，例如硬盘的SMART属性、RAID阵列状态、内存ECC纠错记录和电源冗余状态。第三类是趋势数据，用于观察温度、错误计数、磁盘寿命指标是否持续变化。
采集方式可以结合操作系统代理与带外管理。支持IPMI或Redfish的服务器，能够在操作系统异常时继续提供部分传感器信息；操作系统内则可通过厂商工具和系统日志补充磁盘、内存及驱动事件。两者数据不一致时，应优先核对时间、传感器名称和设备映射，不能直接把重复事件合并。
不要单看阈值，用“指标组合”判断风险
温度告警要关联负载和风扇状态
处理器温度升高并不必然代表故障。短时间高负载、机房进风温度升高，都会造成温度上升。更可靠的规则是：温度超过设备厂商建议范围并持续数分钟，同时风扇转速接近上限，触发严重告警；如果温度升高但风扇转速没有变化，则应优先检查风扇传感器、风扇模块或BMC数据。
温度告警还应设置恢复条件，例如温度回落到告警线以下并持续一段时间后才恢复，避免温度在临界点反复跳变，产生大量恢复和再次告警。
磁盘告警要区分预警信号与阵列故障
SMART中的重映射扇区、待处理扇区和不可校正错误，反映的是介质风险；RAID降级、重建失败或热备盘未就绪，则反映的是数据保护能力。两者不应使用同一等级。
- 单个SMART属性出现异常，但阵列仍正常，可标记为预警，并安排更换窗口。
- SMART错误持续增加，或同一磁盘同时出现读写错误，应升级为高优先级事件。
- RAID降级且没有可用热备盘时，即使业务暂时正常，也应立即通知值班人员。
- 重建期间磁盘延迟和错误继续上升，应避免只等待重建完成，而要检查阵列控制器、背板和剩余磁盘。
内存错误应看累计量、速率和位置
ECC内存的单次可纠正错误不一定需要停机，但同一内存通道、插槽或模块在短时间内反复出现错误，风险明显高于分散的偶发记录。规则可以同时使用“累计次数”和“增长速度”：累计错误超过运维设定值时创建工单；单位时间内快速增加，或出现不可纠正错误、机器检查异常时，直接升级并准备迁移业务。
告警关联的可执行配置方法
- 建立设备基线。记录正常温度、风扇转速、功耗、磁盘错误计数和内存纠错频率。基线应按机型、机房温度和工作负载分别保存，不能把所有服务器使用同一固定值。
- 定义三档严重程度。预警用于趋势变坏，严重告警用于可能影响冗余或性能的状态，紧急告警用于不可纠正错误、双电源同时异常或阵列失去保护等情况。
- 加入持续时间。瞬时温度或电压波动可设置较短观察窗口；磁盘错误和内存错误则应关注计数增长。持续时间通常可从几分钟到十几分钟起步，再依据误报记录调整。
- 设置关联条件。例如“温度高+风扇高转速”指向散热问题，“磁盘错误增长+RAID降级”指向存储风险，“电源掉线+输入异常”指向供电链路问题。
- 配置去重与升级。同一设备的底层传感器事件、系统日志和监控代理事件应绑定设备编号、部件位置和时间窗口。重复告警合并，但不同部件或不同故障链不能盲目抑制。
- 验证恢复和通知链路。用测试环境或维护窗口模拟传感器异常，确认告警能到达值班平台，并验证恢复通知、升级通知和工单字段是否完整。
哪些做法容易造成漏报
一是只采集操作系统指标，服务器关机后就失去硬件信息；二是只设置“超过阈值”规则，忽略错误计数和状态变化；三是把所有重复事件静默，导致真正的第二个故障被掩盖；四是没有监控采集器自身的存活状态，采集停止后平台却没有提示。
服务器硬件资源监控还应增加“数据缺失告警”。当某台设备连续多个采集周期没有返回关键传感器数据时，应将其标记为监控中断，而不是当作硬件恢复。对关键设备，可分别保留带内和带外两条采集路径，降低单一路径失效造成的漏报。
常见问题
硬件告警是否都要立即电话通知？
不需要。趋势预警可进入工单或日报；冗余丢失、不可纠正内存错误和电源异常等事件，才适合即时通知。
温度阈值应统一设置吗？
不应统一。不同处理器、机箱、进风温度和负载条件会改变正常范围，应参考厂商规格并结合本机基线调整。
磁盘SMART正常，为什么还会漏报？
SMART不能覆盖控制器、背板、线缆和阵列状态。应同时采集RAID控制器事件、系统I/O错误和阵列冗余状态。
怎样判断告警规则有效？
定期检查告警是否有明确部件、时间、当前值和处理建议，并统计误报、重复告警、恢复告警及采集中断情况，按月调整规则。
做好服务器硬件资源监控，关键在于把单点读数变成有上下文的故障信号：既看当前值，也看持续时间、增长趋势、部件关系和冗余状态。这样才能在硬件彻底失效前留出处理窗口，同时避免告警泛滥掩盖真正风险。
