ipmitool实战：服务器电源与风扇监控全攻略

半年前有一天机房里一台 2U 服务器凌晨三点突然开始全速吹风那声音像是直升机起飞隔着三排机柜都听得见。我第一反应不是抄起螺丝刀去开箱而是先打开终端敲了一条命令ipmitool sel list。日志里躺着一行Power Unit / Power Supply failure detected后面还跟着Power Supply #0x02。这就是带外管理最实用的地方——操作系统可以没察觉、业务也可以还在跑但 BMC 已经在硬件层记录了异常。ipmitool 就是访问 BMC 最常用的命令行工具这篇文章我会围绕用它监控电源和风扇状态这件事把传感器读取、事件日志定位、转速控制、告警接入和踩坑经验一次讲透。适合机房运维、自建服务器玩家以及任何想把服务器噪音和故障提前摁死的人。1. 带外管理为什么电源风扇监控必须走 IPMI 而不是操作系统1.1 BMC 是藏在服务器里的另一台小电脑先把这个概念说清楚IPMI 不是一类软件它是一套硬件管理接口规范核心是服务器主板上那颗独立的 BMC 芯片。BMC 有自己的处理器、内存、固件、网口电源管理域和主系统完全隔离。服务器就算宕机、蓝屏、断电只要还有 standby 电源BMC 依然活着依然可以回答你的查询。也就是说服务器实际上有两条命一条是跑业务的操作系统另一条是负责“管理自己”的 BMC。ipmitool 就是我们在操作系统里敲门用的工具敲完门之后所有电源状态、风扇转速、温度、电压、日志事件都从 BMC 里拿。很多人第一次接触 IPMI 会觉得多余但如果经历过“服务器起不来、进不了系统、又不知道硬件哪里出了问题”的窘境就会明白这台“另一台小电脑”有多值钱。你用显示器接上去没输出换个内存、拔插显卡折腾一晚上最后发现原来只是电源模块掉线。而用 ipmitool 一查半分钟就能定位。1.2 电源和风扇为什么不能只靠操作系统操作系统层也能看到温度、风扇、功耗吗能比如sensors、powertop、lm-sensors。但有两个硬伤。第一个硬伤是死机后失明。OS 都 panic 了什么工具都起不来。可恰恰是硬件故障最容易先导致系统卡死、重启这时候带外通道是唯一能拿到第一手证据的地方。第二个硬伤是很多电源信息根本不会暴露给 OS。电源模块冗余状态下如果其中一个 PSU 掉了整机还在正常跑Linux 里几乎看不出任何异常。这时你必须靠 BMC 的 SELSystem Event Log才能知道“刚才有一个电源模块发生过掉电事件”。风扇也是这样转速低于阈值但没到停转OS 里未必有进程在管可 BMC 的传感器阈值会先报警。所以我的习惯是凡是机房里的正式服务器一律启用 IPMI 监控而且电源和风扇的状态都是最高优先级。单纯的 OS 层监控只能告诉你“系统还活着”IPMI 监控能告诉你“系统还能活多久”。2. 环境准备ipmitool 安装、内核模块与本地/远程连接2.1 安装 ipmitool 并加载内核驱动ipmitool 在主流发行版仓库里都有安装很简单。Debian/Ubuntu 系执行apt install ipmitoolCentOS/RHEL 系执行yum install -y ipmitool安装后先别急着跑命令本机访问需要内核提供 IPMI 设备接口。一般要加载这几个模块modprobe ipmi_msghandler modprobe ipmi_devintf modprobe ipmi_si加载完确认设备节点出现ls -l /dev/ipmi0如果/dev/ipmi0不存在先不要怀疑 ipmitool去 BIOS 里找 IPMI/BMC 配置确认带外管理功能是否开启。有些低端主板虽然芯片组理论支持但厂商根本没做 BMC设备节点自然出不来。另外部分新内核的中断号变化会导致 ipmi_si 探测失败这时候开机日志里会有提示处理手段通常是加内核参数或者在 BIOS 里改中断方式但绝大多数服务器不会遇到。2.2 本地直连和远程 lanplus 两种模式装好之后在服务器本机执行ipmitool sdr list如果能看到一大串传感器恭喜本地通路已经打通。但实际运维里更多时候是远程操作毕竟机房不一定随时有控制台。远程走 IPMI 2.0 的 RMCP 协议命令格式是ipmitool -I lanplus -H 192.168.10.10 -U admin -P YourPassword sdr list-H是 BMC 的管理 IP-U是 BMC 上的用户名-P是密码。注意在命令行直接写密码ps进程列表里能被人看到这是实操里很容易忽略的安全隐患。更稳妥的做法是不带-P让 ipmitool 交互式地提示输入密码或者在脚本里用-f /path/to/password_file指定密码文件。远程连不上时先从这几点排查BMC 管理口是不是和业务口混在一起、管理 IP 能不能 ping 通、UDP 623 端口有没有被防火墙挡掉、用户名权限是不是太低了。另外老一些的主板可能只支持-I lan而新设备普遍支持-I lanplus两者协议版本不同如果 lanplus 报握手失败可以试一次-I lan对比但这只是排障手段不建议长期使用明文老协议。连接成功后先用ipmitool mc info看看 BMC 的制造商和固件版本这是后续判断命令兼容性的重要依据。2.3 验证传感器基线建立一份“出厂档案”正式投入监控之前我建议跑一次全量传感器读取存成文件留档ipmitool sensor list sensor_baseline.txt ipmitool sdr list sensor_baseline.txt ipmitool sel elist sel_baseline.txt这个动作不是为了应付检查而是给你的服务器建立“健康基线”。等三个月后再跑一次对比风扇转速是不是慢慢抬高了、电压是不是有轻微漂移这些细微变化都是硬件老化或者积灰的信号。3. 电源读数从电源模块传感器到 SEL 事件日志的排查路径3.1 用 sdr type 过滤电源模块传感器电源模块在 IPMI 里的传感器类型是Power Supply直接过滤读就能看到ipmitool sdr type Power Supply在一台配置了双电源的服务器上输出大概是这样的PS1 Status | 0x01 | ok PS2 Status | 0x01 | ok PS1 Presence | 0x01 | ok PS2 Presence | 0x02 | okStatus表示模块本身是否健康Presence表示电源是否在位。如果出现0x00或者状态变成critical、nrnon-recoverable那基本可以断定电源模块异常。除了模块状态电源相关的主板电压传感器也值得看ipmitool sdr type Voltage典型输出会包含3.3V、5V、12V等。别小看这几个电压电源模块输出衰减早期往往不是直接断电而是 12V 电压轻微跌落BMC 的电压传感器会先记录一次 warning。等哪天真断电了你回翻日志会看到电压异常在前、系统崩溃在后那条时间线往往是定位故障的关键。注意不同服务器的传感器命名差异很大。有的叫PS1 Status有的叫PWR1 Presence所以脚本里尽量不要硬编码传感器全名而要充分靠sdr type过滤再辅助关键字匹配。3.2 SEL 是定位电源故障的第一现场传感器实时状态只能告诉你“现在坏没坏”SEL 事件日志才能告诉你“刚才发生了什么”。这也是我喜欢先查sel list的原因。ipmitool sel list ipmitool sel elistsel elist会带更多格式信息和时间戳典型电源故障事件长这样4 | 02/10/2025 | 12:33:21 | Power Unit #0x02 | Power Supply #0x02 | Power supply failure detected 5 | 02/10/2025 | 12:33:22 | Power Unit #0x02 | Power Supply #0x02 | Power supply configuration error这种日志出现后就算当前状态看起来恢复了也说明电源模块至少经历过一次掉电或切换。冗余电源设计里单模块掉电系统不会断但它把系统暴露在了“单点故障”状态下第二块再挂就直接宕机。所以 SEL 里一旦出现 power supply 事件就得安排现场处理而不是等它自己消失。我处理过一台“开机风扇狂转”的戴尔工作站用户说以前从来没这么响过。进 ipmitool 查 SEL发现里面记录了一条 Thermal Trip 事件指向 CPU 附近的温度传感器曾经越过关键阈值。拆开机器才发现散热器下面硅脂已经完全干裂。这种风扇狂转其实是 BMC 的保险机制它宁可让你觉得吵也不敢让芯片烧掉。如果你不查 SEL单纯去 BIOS 里关掉风扇告警甚至用第三方工具把风扇转速压下去那才是真要出事的操作。3.3 实时功耗读取ipmitool dcmi power reading除了状态电源的实时功耗也是运维需要关心的。支持 DCMI 的 BMC 提供了功率读取接口ipmitool dcmi power reading输出会包括当前功耗、最小功耗、最大功耗、平均功耗等信息。这项数据在机房功耗预算、容量规划、以及观察程序负载对整机功耗影响时非常有用。我在压测环境里就常拿功耗读数当参考指标看系统负载上来后风扇策略有没有及时跟上。举个例子如果当前功耗已经 500W而风扇转速还压在低档那下一步很可能是温度飙升。把功耗和风扇转速两个指标放一起看能判断出 BMC 的温控策略是不是处于合理状态。4. 风扇读数转速传感器、4-pin 信号原理与风扇位映射4.1 读取风扇转速与传感器阈值风扇类型的传感器通过sdr type过滤ipmitool sdr type Fan输出大致如下FAN1 | 7200 RPM | ok FAN2 | 7150 RPM | ok FAN3 | 10800 RPM | ok FANA | 10800 RPM | ok只看当前值还不够热插拔服务器机箱风扇有上下限阈值一旦转速落到下限附近说明轴承磨损、积灰或者供电不足。用sensor get能看到更完整的阈值定义ipmitool sensor get FAN1输出里的关键字段大致包括字段含义Sensor Reading当前读取到的转速Status当前状态ok / warning / criticalLower Critical低于此值会触发 critical 告警Lower Non-Recoverable低于此值会被判定为不可恢复故障Upper Critical高于此值会触发 critical 告警很多初次接触 IPMI 的人只关心当前转速却忽略了阈值。其实阈值才是 BMC 自动决策的依据。风扇转速如果已经非常接近 lower critical 但还没报警你就要提前安排处理了别等触发告警再动手。4.2 从 4-pin 风扇接口理解转速和 PWM 的原理服务器风扇大多采用 4-pin 接口这和消费级主板上常见的 CPU 风扇、机箱风扇接口是同一套定义Pin 1 GNDPin 2 12VPin 3 TACH 测速信号Pin 4 PWM 调速信号。BMC 读取转速本质上是通过 TACH 引脚上产生的脉冲频率换算出来的而调节转速则是通过 PWM 改变占空比也就是改变有效供电电压的平均值来转动快慢。理解了这套信号逻辑你再看ipmitool里的传感器读数就不只是一个抽象数字了——它背后是一条实打实的测速线。普通 PC 主板没有 BMCLinux 下的pwmconfig、fancontrol也能通过 Super I/O 芯片做类似的事情但服务器不一样BMC 拥有独立控制回路即使操作系统已经卡死风扇策略依然还由 BMC 兜底。这也是为什么我坚持服务器风扇监控要走 IPMI。4.3 风扇位映射FAN1 到底对应机箱哪个位置这是最容易被忽略却也最影响排障效率的问题。ipmitool sensor list里的 FAN1、FAN2 是主板上的逻辑编号不一定和机箱前面板从左到右的物理位置一一对应。不同品牌服务器的映射关系都不一样有的甚至 FAN1 在 CPU 附近FANA 才是机箱中部风扇。靠谱的做法是在新机器进场时做一次物理映射带着机箱盖逐个断开风扇电源线或者用手轻轻挡住风扇出风注意安全别用硬物去捅正在转的扇叶看 ipmitool 里哪个传感器读数掉到 0把对应关系记下来。用一张表维护好面板位置传感器名备注前置左侧FAN1对应硬盘背板散热前置右侧FAN2对应硬盘背板散热CPU 散热器FAN3也可以记为 FANB后置电源上方FANA与电源模块相邻以后告警来了你直接看告警里的传感器名就知道是该去拆前面板还是开后盖不用再现场拆机器一个个猜。5. 调速实战静音改造里的 raw 命令和温控脚本5.1 为什么要手动调速厂商默认的 BMC 风扇策略通常非常保守宁可转速高一点、噪音大一点也要保证散热余量。家用或者办公室场景里一台 2U 服务器满载时那风扇声确实让人崩溃。很多人想静音改造第一反应是去 BIOS 里调风扇级别但服务器层面的风扇控制其实主要掌握在 BMC 手里BIOS 里的选项往往只有 auto/optimal/full speed 几档。ipmitool 的 raw 命令可以在一定程度上干预风扇策略。但我要先泼一盆冷水手动调速意味着绕过了厂商验证过的自动化逻辑一旦转速过低导致散热不足轻则降频重则过热关机数据丢失。所以我的原则是只在家用/测试环境折腾生产机房的机器尽量别这么干。5.2 不同厂商的 raw 命令怎么找IPMI 标准协议里没有规定统一的风扇调速命令各家用的是厂商自定义 OEM 命令。也就是说超微、戴尔、浪潮、惠普的 raw 命令字节很可能完全不一样甚至同一品牌不同型号都会变。以超微部分服务器为例网上普遍流传的玩法是ipmitool raw 0x30 0x45 0x01 0x01 # 切换为手动模式 ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x64 # 设置对应 zone 的 PWM 为 100% ipmitool raw 0x30 0x45 0x01 0x00 # 切回自动模式注意这类命令没有任何跨厂商通用性甚至超微自己不同固件版本的 zone 编号含义都可能不一样。所以我不会在这里拍胸脯说一份命令走天下。正确的操作流程是先去官网查这台型号的 IPMI 用户指南或者找厂商技术要 OEM 命令表然后在测试机上执行并观察sdr type Fan的变化。修改前把当前传感器状态留档修改时让风扇转速一点一点加不要一上来就 100%。戴尔的服务器更建议走 iDRAC 的管理界面或者 racadm 工具浪潮服务器则要看其官网的 IPMI 配置工具避免为省事直接套用超微命令导致 BMC 状态混乱。5.3 一个温控联动脚本自己接管风扇之后最怕的就是转速定死环境温度一变却没有响应。比较稳妥的办法是写一个脚本周期性读温度传感器根据温度区间自动调整风扇转速。下面是一个 Bash 思路示例注意 raw 命令需要替换成你服务器实际的指令#!/bin/bash BMC_IP10.0.0.10 BMC_USERadmin BMC_PASSsecret get_temp() { ipmitool -I lanplus -H $BMC_IP -U $BMC_USER -P $BMC_PASS \ sdr type Temperature | grep CPU Temp | awk -F| {print $2} | tr -d } while true; do TEMP$(get_temp) if [ -z $TEMP ]; then sleep 60 continue fi if [ $TEMP -ge 75 ]; then PWM80 elif [ $TEMP -ge 65 ]; then PWM55 elif [ $TEMP -ge 55 ]; then PWM35 else PWM25 fi ipmitool -I lanplus -H $BMC_IP -U $BMC_USER -P $BMC_PASS \ raw 0x30 0x70 0x66 0x01 0x00 $PWM /dev/null 21 sleep 30 done脚本里最关键的细节是获取温度失败时宁可继续跑下一轮也不能给风扇设一个比较低的固定值。因为读不到温度说明网络或者 BMC 可能已经出问题了这时候如果把风扇转速降下来风险会非常大。5.4 手动调速的安全边界我吃过一次亏。早年间在一台家用服务器上调风扇把命令写错结果机器恢复了自动模式后风扇依然全速运转折腾了十分钟才发现是 raw 参数里 zone 编号填错导致 BMC 把某个区当成了“未知硬件”处理。从那以后我给自己立了两条规矩第一条任何 raw 命令执行前先把当前模式、当前传感器状态完整记录下来。第二条脚本里必须带心跳异常退出时自动切回自动模式。Bash 里可以简单用trap处理退出信号让脚本被 kill 或断网时执行ipmitool raw 0x30 0x45 0x01 0x00。如果你用的不是超微还是那句话切回自动模式的命令同样要看厂商手册。不要以为伺服器的 BMC 很耐用就随便折腾连续错误 raw 命令有可能让部分 BMC 固件进入低速保护甚至直接显示系统故障只能靠重启 BMC 恢复对于在跑业务的机器来说代价不小。6. 避坑笔记权限、厂商差异、误报与 SEL 清空策略6.1 权限和连接问题是头号拦路虎本地执行 ipmitool 最常见的坑是权限不足。设备节点/dev/ipmi0默认只有 root 能读普通用户直接跑会看到Could not open device at /dev/ipmi0: Permission denied解决办法很直接sudo执行或者把用户加入对应的设备权限分组再就是配置 udev 规则不必每次都提权。远程连接时报错多数集中在几个点。一个是用户名权限级别不够常见报错Get Session Challenge failed, status 0x0c Insufficient privilege这是 BMC 上配置的远程用户只有 operator 或者 read-only 权限而命令需要 ADMIN 权限。处理方法是去 BMC Web 界面把用户权限调到 admin或者换一个管理员账号。另一种情况是连接超时。BMC 网络和管理网 VLAN 不通是很常见的因为很多服务器的带外口是独立网口要单独接交换机。排查思路是先看管理口是否拿了 IP再从你的运维网络能不能路由到它最后检查防火墙有没有放开 UDP 623 端口。6.2 厂商自定义 SDR 的命名陷阱IPMI 是一个标准协议但各家在设计 SDRSensor Data Record时命名很随意。我见过同一个品牌同一代产品新固件把CPU Temp改成了CPU1 Temperature导致部署好的监控脚本一夜之间读不到温度。应对办法是在脚本里做模糊匹配避免完全依赖全名。命令行交互时要先跑一轮ipmitool sensor list | grep -i temp看看实际传感器名称再写过滤条件。更稳妥的做法是让脚本基于sdr type Temperature这类类型过滤而不是直接sensor get CPU Temp。另外很多厂商的 OEM raw 命令没有公开文档问渠道商经常也拿不到。这时候可以拿两台同样的机器做对照但别拿不同型号的机器猜。我曾见过有人在网上发帖问“为什么我的浪潮服务器用超微命令无效”底下评论一堆最后才发现两者根本不是同一个 BMC 方案。6.3 误报、SEL 满与风扇积灰风扇转速告警并不总是意味着风扇要坏了。最典型的场景是积灰。机器在机房跑了两年风扇叶片上全是灰转速读数可能只降了一点但风力已经明显下降传感器温度却在缓慢上升。这种“转速正常、温度偏高”的组合清灰之后往往能恢复很多。还有一种情况是瞬时误报。电源模块在短暂电压跌落时SEL 里会多一条 warning 事件但当前传感器状态已经恢复 ok。如果不看时间戳只看到 SEL 里有事件就判断电源损坏容易造成乌龙。我的建议是告警判断要以当前实时传感器为主SEL 事件作为辅助定位的证据链。SEL 满也是常见问题。BMC 的日志空间不大大量告警事件会把 SEL 撑满满了之后 BMC 可能停止写入新日志导致后面真正有价值的事件丢失。处理流程是ipmitool sel elist sel_backup_$(date %F).txt ipmitool sel clear清空前一定要备份这是经验。因为 SEL 里不仅包含电源风扇事件系统意外重启、内存纠错记录都会在里面有时这些记录是后续排查故障的唯一线索。7. 把 IPMI 接进告警健康检查脚本与监控平台对接7.1 一个可以直接改用的健康检查脚本状态读出来了最终要落到告警上。下面是一个简化但可用的 Bash 脚本轮询电源模块状态和错误事件发现异常就发一封邮件#!/bin/bash BMC_IP10.0.0.10 BMC_USERadmin BMC_PASSsecret ALERT_EMAILopsexample.com HOSTproduction-srv-01 PSU_STATUS$(ipmitool -I lanplus -H $BMC_IP -U $BMC_USER -P $BMC_PASS \ sdr type Power Supply 21) if echo $PSU_STATUS | grep -Eiq critical|nr|0x00|no presence; then echo -e Host: $HOST\nTime: $(date)\n$PSU_STATUS | \ mail -s [ALERT] PSU Abnormal on $HOST $ALERT_EMAIL fi SEL_TAIL$(ipmitool -I lanplus -H $BMC_IP -U $BMC_USER -P $BMC_PASS \ sel elist 21 | tail -20) if echo $SEL_TAIL | grep -Eiq power supply|power unit; then echo -e Host: $HOST\nRecent SEL:\n$SEL_TAIL | \ mail -s [ALERT] SEL Power Event on $HOST $ALERT_EMAIL fi把这个脚本丢进 crontab每分钟跑一次最多只能算“能用”。但要注意两点cron 里不要直接把密码写在命令行否则日志里会泄露另外所有 ipmitool 远程命令都是同步等待 BMC 响应的如果 BMC 网络卡顿脚本也会被拖住建议在命令外层加timeout 10 ipmitool ...避免脚本堆积。7.2 对接 Zabbix 和 Prometheus 的正确姿势如果你的监控体系已经比较成熟直接用脚本去轮询并不是最优解。Zabbix 本身支持 IPMI 监控在主机配置里填好 BMC IP 和用户名密码模板选择 IPMI sensors 相关项Zabbix Server 会替代你执行 ipmitool 读取。优点是配置之后传感器项自动发现不用自己写解析脚本。缺点是 Zabbix 轮询频率如果设得太高BMC 的响应会变慢甚至影响带外稳定性建议轮询间隔至少 60 秒以上。Prometheus 生态里有比较成熟的ipmi_exporter会周期性抓取 SEL、传感器数值并以标准 metrics 形式暴露出来。之后你能在 Grafana 里做风扇转速趋势、PSU 状态、历史事件统计等面板也能对ipmi_sensor_value{nameFAN1}这类指标配置告警规则。如果你运维体系已经以 Prometheus 为主这条路更顺。不管是 Zabbix 还是 Prometheus核心原则都一样不要自己发明一套采集层除非你只是想临时用脚本顶一下。7.3 把基线数据变成长期资产最后分享一个投入产出比很高的习惯每次巡检时把sensor list和sel elist存档按日期归档。几个月你把数据拉出来对比能明显看到同一台机器的风扇转速在逐年缓慢上升或者电源模块的电压读数有微小漂移。这些趋势比单次告警更能反映硬件健康度。有一次我就是在月度对比里发现某台服务器 12V 电压逐月下降了 0.2V当时没有任何传感器报警但提前换了电源模块避免了两个月后可能出现的随机重启。ipmitool 看起来只是个命令行小工具但把它用充分你其实同时拿到了远端开关机、硬件状态、历史日志、功耗监控、串口管理一整套带外能力。电源和风扇只是其中最直接、最常用的两个切入点。等你自己把第一条sel list跑通你会发现服务器这玩意儿比想象中透明得多。