服务器硬件健康检查关键在于实时告警：通过IPMI获取温度、风扇、电压等指标，转换为Prometheus可采集格式，配置分级告警规则并联动通知渠道，同时验证机制与采集器自身健康监控兜底。

服务器硬件健康检查要真正起作用，关键不是“能看”，而是“出问题时立刻知道”。把硬件状态接入监控系统并自动告警，核心在于两点：一是让硬件指标变成监控系统能采集的数字，二是用规则定义“什么算异常”并触发通知。

用IPMI获取底层硬件指标

IPMI是绕过操作系统的硬件监控通道，即使系统卡死、内核崩溃，只要BMC供电正常，温度、电压、风扇转速、电源状态等数据依然可读。在Ubuntu或CentOS上装好ipmitool后，一条命令就能拿到实时值：

• ipmitool sdr type temperature 查CPU/主板/电源温度
• ipmitool sdr type fan 查各风扇转速（RPM）
• ipmitool sdr type voltage 查12V/5V/3.3V等供电电压
• ipmitool sensor list 一次性列出所有传感器状态

这些输出可以被脚本定时抓取，转换成Prometheus能识别的文本格式（如ipmi_temp_celsius{sensor="CPU_Temp"} 68.2），再通过Node Exporter的textfile collector暴露出去。

把硬件指标写进Prometheus告警规则

Prometheus本身不直接采集IPMI，但你可以用轻量脚本做“翻译层”。比如每分钟运行一次Python脚本，调用ipmitool，解析结果，生成临时指标文件。然后在Prometheus里加一条规则：

• ALERT IPMIFanFailure
IF ipmi_fan_rpm{sensor=~"FAN.*"} < 1000
FOR 2m
ANNOTATIONS {summary = "风扇{{ $labels.sensor }}转速低于1000 RPM"}
• ALERT IPMITemperatureHigh
IF ipmi_temp_celsius{sensor="CPU_Temp"} > 85
FOR 1m
ANNOTATIONS {summary = "CPU温度{{ $value }}°C，超过阈值85°C"}

注意：温度类指标建议设短持续时间（如1分钟），因为升温快；风扇类可设稍长（如2分钟），避免瞬时波动误报。

告警分级与通知渠道联动

硬件告警不能一概而论。电源故障、CPU过热必须立刻响应，而某个次要风扇停转可先发邮件、不打手机。AlertManager支持按标签分组和路由：

• 给IPMI告警统一加标签：severity: "critical"（电源/温度）或severity: "warning"（风扇/电压偏差）
• 在AlertManager配置中，把severity=critical的告警路由到企业微信+电话机器人，severity=warning只推送到钉钉群
• 加一条抑制规则：当IPMIPowerFailure触发时，自动抑制所有其他IPMI告警——避免电源断电后一堆风扇、温度告警刷屏

验证与兜底机制

再完善的配置也要验证是否真能工作。最简单的办法是手动触发一次异常：

• 用ipmitool raw 0x30 0x30 0x01 0x00关闭一个风扇（仅限测试环境！）
• 等2分钟后看AlertManager是否生成告警，并检查通知是否收到

更重要的是设计失败兜底：监控脚本自己挂了怎么办？建议把脚本执行状态也作为指标上报（例如ipmi_collector_last_success_timestamp），再配一条规则——如果这个时间戳超过5分钟没更新，就告警“IPMI采集器离线”，确保监控系统自身健康。