机房里的服务器半夜报警，值班同事盯着远方管理系统里跳出来的红色告警，第一反应不是去机房而是先远程敲一条ipmitool sdr list，看看风扇转速和电源状态是不是还正常。这种情况在数据中心里太常见了，而“ipmitool监控电源风扇状态”这件事，也确实是服务器运维里最基础但又最容易被做糙的一块。
这篇文章就是围绕这个场景来写的。我会从环境搭建开始，把常用命令、输出解析、阈值判断，以及怎么通过 raw 命令调整风扇策略都过一遍，最后再聊聊我自己踩过的一些坑。适合刚接手服务器运维的工程师、自己在家玩二手服务器的玩家，以及想在带外管理上补一课的朋友。读完你至少能做到：不登录系统、不开机箱，就把电源和风扇的健康状况摸个七七八八。
1. 为什么服务器管理员都在用 ipmitool 盯电源和风扇
1.1 服务器管理里最容易被忽略的“沉默部件”
对于一台已经稳定运行的服务器，CPU 占用率、内存使用率、磁盘 IO 这些指标会被盯得很死，但电源和风扇往往是出了问题才被注意到的。这俩部件平时不说话、没有可交互的界面，等到风扇狂转或者电源模块报警的时候，往往已经影响到了业务或者正在逼近宕机边缘。
电源模块失效是个缓慢的过程，通常不是瞬间断电，而是电压纹波变大、输出功率下降、模块温度持续偏高。像 750W 的冗余电源，如果一只已经带不动负载，另一只就会默默扛下所有，这种状态下表面看系统还在跑，实际上已经没有冗余能力了。风扇也是一样，转速掉下去、轴承开始磨损，短时间内机器不会重启，但 CPU 或者内存的温度会开始缓慢爬坡，等温度撞到保护阈值，整机直接掉电，连报错日志都来不及写。
ipmitool 的价值就在于，它能通过独立的带外管理通道直接读取这些硬件的传感器数据，不需要进操作系统，也不需要装驱动。主板上的 BMC（基板管理控制器）从开机那一秒就在工作，它独立于 CPU 和操作系统运行，只要服务器插着电源线、连着管理网口，你就能从远程把电源和风扇的状态全部拉出来。
1.2 ipmitool 到底能监控什么：从传感器到事件日志
很多人以为 ipmitool 只有一个sensor list命令，实际上它的能力覆盖硬件管理的方方面面。单就电源和风扇监控来说，我日常最常用的是这几个层面：
- 传感器实时读数：风扇转速、电源模块温度、各路电压、系统总功耗，这些由 BMC 定时采样并缓存在 SDR（Sensor Data Record）里，通过
ipmitool sdr list或ipmitool sensor list能一次性拿全。 - 传感器事件日志：BMC 不仅记录“当前电压是多少”，还会记录“某年某月某日电压越过阈值”，这些事件会写进 SEL（System Event Log），用
ipmitool sel list可以回溯整个硬件的历史健康状况。 - 电源模块与整机状态：
ipmitool chassis status能看到电源是否正常、是否处于开机状态、上次关机原因；ipmitool dcmi power reading能直接读到当前功耗，对评估电源负载率非常有帮助。 - FRU 信息：
ipmitool fru print能读出电源模块的厂家、型号、序列号、额定功率等字段，这在核对硬件配置和保修信息时特别有用。
换句话说，通过 ipmitool 这一条通道，你可以把电源和风扇从“硬件黑盒”变成“可观测的部件”。接下来我按实操顺序，从环境搭建开始讲。
2. 搭建监控环境：ipmitool 安装与带外连接
2.1 工具安装：不用编译也能用
ipmitool 是一个老牌开源工具，绝大多数 Linux 发行版的软件源里都有，直接装就行。
Debian/Ubuntu 系：
apt install ipmitoolRHEL/CentOS/Rocky 系：
yum install ipmitool如果管理机是 Windows，可以到主板厂商或开源镜像站找 Windows 编译版本，也可以直接用 WSL 装 Linux 版。macOS 用 Homebrew 装brew install ipmitool也行。这里需要说一句，如果服务器自带的管理软件（比如 Dell iDRAC、HP iLO、浪潮 BMC 的 Web 管理台）已经能看风机转速，你确实可以不用命令行，但 ipmitool 的优势是脚本化、可批量、能接入监控平台，这些都是 Web 界面很难做到的。
安装完先验证一下版本：
ipmitool -V2.2 打通 BMC 网络：硬件的零配置通信通道
有了工具，下一步是让管理机能够访问服务器 BMC。BMC 通常有一个独立的管理网口，可能是专门的 IPMI 口，也可能是共享的业务网口。不同厂商机器的默认 IP、默认账号密码各不相同，这个在第一次开机自检界面就能看到，也建议第一时间改成自己管理的地址和强密码。
本地服务器上用内核模块方式访问最省事，前提是主板开启了 IPMI 的 KCS 接口支持：
ipmitool sensor list这是本机直连 BMC 的方式，不经过网络，适合人在服务器旁边、或者通过 SSH 登录到服务器上排查问题。我们日常运维中很多操作都是这样用，优点是不需要知道 BMC 的 IP 和账号，只要操作系统里能看到/dev/ipmi0或者类似设备就行。
远程访问则是生产环境用的最多的方式，使用lanplus接口类型走 lan 管理网络：
ipmitool -I lanplus -H 192.168.1.10 -U admin -P 'your_password' sensor list这里-I lanplus表示用 IPMI 2.0 的 RMCP+ 协议，-H指定 BMC 的 IP，-U和-P分别是用户名和密码。IPMI 默认监听 623 端口，管理机上要确保防火墙放行这个端口。
如果不想每次都在命令行里带密码，可以用环境变量配合-E参数：
export IPMITOOL_PASSWORD='your_password' ipmitool -I lanplus -H 192.168.1.10 -U admin -E sensor list这样密码不会出现在 shell 历史里，多台机器管理时也方便些。
2.3 权限、账号与安全基线
IPMI 是带外管理通道，权限极高，可以把服务器开机、关机、重启，还能读取所有传感器，所以账号安全一定要重视。很多旧服务器的 BMC 默认密码是弱口令，上线前必须改掉。
检查当前 IPMI 用户列表：
ipmitool -I lanplus -H 192.168.1.10 -U admin -P 'your_password' user list输出的表格里有用户 ID、用户名、权限级别（Administrator/Operator/User/No Access）、是否启用等字段。我个人的建议是：
- 保留至少一个具有 Administrator 权限的本地位账号，用于带外管理，密码用独立的强密码。
- 如果只做监控，可以单独建一个 User 权限的账号，只授权传感器读取和 SEL 查询，不给电源控制权限。
- 关闭不需要的匿名访问或默认账号。
- 管理网口尽量放在独立的 VLAN 里，不要直接暴露在业务网络或公网。
这里有一个坑我需要提醒：很多人在sensor list报权限错误时，第一反应是“传感器坏了”，实际上很可能就是当前账号权限不够。IPMI 用户的权限级别直接决定了你能不能读到传感器数据，某些厂商的 BMC 固件里，Operator 权限也不一定能看到全部传感器，所以监控账号至少得是 Operator 以上，最好是 Administrator。
3. 核心实操：电源与风扇状态监控命令全解
3.1 正确姿势读取传感器数据（sdr/sensor）
登上去之后，第一件事是拉全量传感器列表：
ipmitool -I lanplus -H 192.168.1.10 -U admin -P 'your_password' sdr list这个输出会把所有传感器混合在一起，包括 CPU 温度、主板温度、风扇转速、各路电压、电源状态。数据量比较大，所以我通常会配合 grep 过滤关键字：
ipmitool sdr list | grep -E "FAN|PS|POWER|V_|TEMP"还有一种更结构化的方式是用sensor list：
ipmitool sensor list两者的区别在于，sdr list显示的是 SDR 记录里的当前值，sensor list会额外显示每个传感器的上下限阈值。对于判断风扇转速是否正常，sensor list更直观，因为它直接告诉你当前读数距离上限、下限还有多少余量。
以一台常见 2U 服务器为例，输出大概长这样：
CPU1_TEMP | 52.000 | degrees C | ok | 0.000 | 0.000 | 0.000 | 85.000 | 90.000 | 95.000 CPU2_TEMP | 48.000 | degrees C | ok | 0.000 | 0.000 | 0.000 | 85.000 | 90.000 | 95.000 FAN1 | 10240.000 | RPM | ok | 500.000 | 600.000 | 700.000 | 25500.000 | 25500.000 | 25500.000 FAN2 | 10241.000 | RPM | ok | 500.000 | 600.000 | 700.000 | 25500.000 | 25500.000 | 25500.000 FAN3 | 7168.000 | RPM | ok | 500.000 | 600.000 | 700.000 | 25500.000 | 25500.000 | 25500.000 FAN4 | 7169.000 | RPM | ok | 500.000 | 600.000 | 700.000 | 25500.000 | 25500.000 | 25500.000 PS1_STATUS | 0x01 | discrete | 0x0180 | 0x0000 | 0x0000 | 0x0000 PS2_STATUS | 0x01 | discrete | 0x0180 | 0x0000 | 0x0000 | 0x0000 PS1_TEMP | 40.000 | degrees C | ok | 0.000 | 0.000 | 0.000 | 75.000 | 80.000 | 85.000 POWER_METER | 628.000 | Watts | ok | 0.000 | 0.000 | 0.000 | 1200.000 | 1300.000 | 1400.000这段输出里的每一列都有意义。风扇的阈值列从左到右分别是 LNR（下限不可恢复）、LCR（下限临界）、LNC（下限非临界）、UNC（上限非临界）、UCR（上限临界）、UNR（上限不可恢复）。如果当前值低于 LNC 或者高于 UNC，状态列就会从 ok 变成 nr/cr。也正是因为这些阈值在 SDR 里是静态的，所以我们可以据此写监控规则。
3.2 电源模块状态与功耗读数
电源模块是故障率偏高的部件之一，尤其运行了三五年的服务器，电源里的电解电容和风扇轴承都在老化。ipmitool 里看电源状态最常用的传感器名是PSx_STATUS、PSx_Input、Power Supply这类，不同厂商命名略有差异。
如果想快速一览：
ipmitool sdr list | grep -i "PS"PS1_STATUS这类传感器一般是 discrete 类型，它不像风扇转速那样输出一个连续数值，而是一组状态位。比如常见的0x0180表示“存在且状态正常”，0x0200可能表示“电源故障”，具体含义要看厂商的传感器 PDR 定义。实际使用中，别太纠结于每一位的编码含义，重点看状态列是不是 ok，以及是否有告警。
除了状态，整机功耗也是必须盯的数据。现代服务器大多支持 DCMI（Data Center Management Interface），直接读取：
ipmitool dcmi power reading输出示例：
Instantaneous power reading: 608 Watts Minimum during sampling period: 532 Watts Maximum during sampling period: 642 Watts Average power reading over sample period: 593 Watts这个数据对判断电源负载率非常有价值。我一般把瞬时功耗除以电源总额定功率，算出一个负载百分比。比如说一台双电源 1600W 的服务器，瞬时功耗 640W，单个电源负载约 40%，如果另一只电源故障，剩下的那只负载就是 80%，已经不算健康了。如果用不到冗余能力，或者业务扩容后功耗明显上升，应该在监控里对电源负载率设置单独的告警，而不是只等电源模块彻底挂掉。
3.3 风扇转速、状态与阈值判断
风扇传感器是服务器的“呼吸系统”指标。CPU 可以因为降频硬撑，但风扇一旦失效，热量散不出去，整机就只能在重启时留下措手不及的记录。
看风扇状态我建议用单独的传感器查询，而不是每次刷全量：
ipmitool sensor get "FAN1"某个具体传感器的输出会更详细，包括当前值、状态、阈值上下限、正负变化率等字段。例如：
Locating sensor record... Sensor ID : FAN1 (0x30) Entity ID : 7.1 (System Board) Sensor Type (Discrete): Fan Sensor Reading : 10240.000 ± 0.000 RPM Status : ok Nominal Reading : 12000.000 Normal Minimum : 3000.000 Normal Maximum : 25000.000 Lower critical : 600.000 Lower non-critical : 700.000 Upper critical : 25500.000 Upper non-critical : 25500.000判断风扇是否正常的核心逻辑是三看：
- 看读数：是否在某一个稳定区间。高负载时转速上升、空闲时下降是正常的，异常的是转速突然掉零或持续贴在低阈值附近。
- 看状态：状态列是否是 ok。如果出现 nr、cr，说明超过了不可恢复或临界阈值。
- 看历史：
ipmitool sel list里是否出现过 Fan 相关的告警事件。瞬时抖动的风扇，在传感器当前值里可能看不出问题，但 SEL 会留下“Fan speed out of range”的事件记录。
把这三条逻辑固化到监控脚本里，能过滤掉很多无效告警。我曾经遇到一台 4U 存储服务器，FAN5 每隔几天就报一次非临界下限，当前值又都正常，后来排查就是风扇轴承间歇性卡涩，靠 SEL 里的历史事件才定位到。
3.4 把状态拉进监控系统
单台服务器手动执行命令没问题，但几十台上百台机器，还是得脚本化。最基础的做法是用一个循环去拉所有服务器的关键传感器：
#!/bin/bash HOSTS=("bmc01" "bmc02" "bmc03") for host in "${HOSTS[@]}"; do echo "===== $host =====" ipmitool -I lanplus -H "$host" -U admin -E sdr list \ | grep -E "FAN|PS|POWER_METER" done更进一步，可以把采集到的数据推给 Prometheus、Zabbix 这类监控平台。思路很简单：定时执行 ipmitool 采集，输出 metrics 格式的数据，然后让监控系统抓取。以下是一个简化版的 exporter 片段，用脚本把关键传感器转成 Prometheus 文本格式：
#!/bin/bash IPMI_HOST="192.168.1.10" IPMI_USER="monitor" export IPMITOOL_PASSWORD='your_password' sensor_data=$(ipmitool -I lanplus -H "$IPMI_HOST" -U "$IPMI_USER" -E sensor list) echo 'ipmi_power_meter_watts{host="server01"} '"$(echo "$sensor_data" | grep '^POWER_METER' | awk '{print $2}')" echo 'ipmi_fan1_rpm{host="server01"} '"$(echo "$sensor_data" | grep '^FAN1' | awk '{print $2}')"这只是一个最朴素的写法，真实落地时建议直接用社区现成的 ipmi_exporter，没必要重复造轮子。关键点是：别只采集 CPU 温度，电源功耗、风扇转速这两个指标一定要放进监控面板和告警规则里。
4. 高级玩法：用 ipmitool 调整风扇转速策略
4.1 从自动到手动：OEM raw 命令的底层逻辑
服务器风扇转速策略通常由 BMC 固件决定，基于 CPU、内存、硬盘等温度传感器做 PID 调节。但实际使用中，BMC 的策略并不总是符合我们的需求。比如家用的实验室服务器装了低功耗 CPU，BMC 依然按数据中心散热模型把风扇拉到 8000 转，噪音大到没法放在工位旁边；反过来，某些高密度 GPU 服务器在机房里温度升高时，风扇策略响应又偏保守，需要人为干预。
ipmitool 可以通过raw命令直接向 BMC 发送 OEM 字节序列，把风扇策略从自动切到手动。以很多 x86 服务器通用的 Intel IPMI OEM 命令为例：
切换到手动模式：
ipmitool raw 0x30 0x30 0x01 0x00设置全部风扇转速百分比，十六进制表示的转速值，例如设置 50% 左右：
ipmitool raw 0x30 0x30 0x02 0xff 0x32切回自动模式：
ipmitool raw 0x30 0x30 0x01 0x010xff表示这组转速设置应用到所有风扇，0x32是十六进制的 50（约 50% 转速档位，具体百分比与厂商实现有关），0x64就是 100%，0x00是最低转速。
我自己实测过，这条命令在部分戴尔和浪潮机器上是有效的，设置完风扇转速会明显变化。但这里必须非常强调一句：不同厂商、不同 BMC 固件的 OEM 命令都不一样，0x30 0x30系列是很多 Intel 平台服务器通用的，但并非所有厂商都支持。
4.2 不同服务器厂商的转速控制差异
我简单列一下主流厂商的常见差异，方便你对照自己手头的设备：
| 厂商/平台 | 常见控制方式 | 注意事项 |
|---|---|---|
| 戴尔 PowerEdge | ipmitool raw 0x30 0x30 0x01 0x00手动，0x30 0x30 0x02 0xff 0xXX设定转速 | 低版本固件也可能用 iDRAC 的 IPMI 命令，重启后策略可能恢复 |
| 浪潮 | 部分机型同样支持0x30 0x30系列 | 新机型建议先用ipmitool raw 0x30 0x30 0x01 0x01验证是否有响应 |
| HPE | 一般不建议用 raw 命令，优先 iLO 的 GUI 或 RESTful API 设置 | iLO 固件对 raw 命令限制较多，强行发送可能无效 |
| Supermicro | ipmitool raw 0x30 0x45 0x01 0x00手动，0x30 0x70 0x66 0x01 0x00等模式 | 型号差异极大，老平台和新平台的命令不通用 |
| 联想 | 多用 XCC 管理，命令行 raw 支持有限 | 建议走 XCC 的 Web 或 Redfish API |
之所以有这么多差异，是因为 IPMI 规范只定义了传感器、SEL、FRU、机箱控制这些标准命令，风扇策略属于厂商私有命令范围，每家的实现方式都不一样。所以在生产环境批量调整风扇之前，一定要先在测试机上验证命令是否生效，别拿着网上搜来的命令直接往几百台上推。
4.3 脚本化风扇曲线：一台静音同时又安全的 NAS/工作站
如果你是在家里或者小办公室运行一台服务器，BMC 的风扇策略很可能让你觉得“有点吵”。这时候可以把手动调速做成一个周期性任务，按负载自动调节转速，兼顾温度和噪音。
核心思路是：
- 先用手动模式接管风扇控制。
- 定时读取 CPU 温度传感器和风扇转速。
- 根据温度档位设定对应的转速百分比。
- 如果温度超过安全阈值，直接切回自动模式兜底，避免人为调速导致散热不足。
我用一个简单的 bash 脚本实现过这个逻辑：
#!/bin/bash IPMI_HOST="192.168.1.10" IPMI_USER="admin" export IPMITOOL_PASSWORD='your_password' get_cpu_temp() { ipmitool -I lanplus -H "$IPMI_HOST" -U "$IPMI_USER" -E sensor get "CPU1_TEMP" \ | grep "Sensor Reading" | awk '{print $4}' } set_fan_speed() { local pct=$1 local hex=$(printf '%x' "$pct") ipmitool -I lanplus -H "$IPMI_HOST" -U "$IPMI_USER" -E raw 0x30 0x30 0x02 0xff "0x$hex" } ipmitool -I lanplus -H "$IPMI_HOST" -U "$IPMI_USER" -E raw 0x30 0x30 0x01 0x00 while true; do temp=$(get_cpu_temp) if [ "$temp" -ge 70 ]; then set_fan_speed 100 elif [ "$temp" -ge 60 ]; then set_fan_speed 70 elif [ "$temp" -ge 50 ]; then set_fan_speed 50 else set_fan_speed 30 fi sleep 30 done这个脚本思路很直观，但我必须泼几盆冷水：
- CPU 温度测量点不止一个，建议同时看
CPU2_TEMP、Ambient_TEMP，不要单一温度驱动。 - 风扇转速百分比与实际 RPM 不是线性关系，不同转速档位之间的声学差异很大，需要实测。
- 手动模式下的风扇转速不会因为系统负载变化自动升高，所以温度阈值必须保守一些。
- 每次 BMC 重启、服务器重启之后，策略大概率会恢复成自动模式，脚本要有重入手动模式的机制。
- 不要在一个脚本里既做监控又做控制，至少把采集脚本和控制器分离，否则监控程序故障会导致风扇策略失控。
5. 故障排查与避坑实录
5.1 有传感器却没有读数怎么办
最让人头疼的情况就是：sensor list能看到传感器条目，但读数是na或者No Reading。这不一定代表传感器坏了，要分情况看。
第一类情况是传感器本身未启用。有些服务器在 BIOS 或 BMC 设置里可以开关传感器，比如“电源冗余状态传感器”，未启用时就显示na，这时候需要进 BIOS/BMC 把对应开关打开。
第二类是 IPMI 通道配置问题。在lanplus模式下，如果某个传感器的读数始终不出，可以先试试本地 KCS 通道：
ipmitool sensor list如果本地能读到，远程读不到，那就是 lan 通道的传感器访问权限没给全，或者 BMC 固件的 lan 通道存在已知 bug，可以先升级固件试试。
第三类是传感器被屏蔽。部分 OEM 机型在出厂时确实不会让某些传感器暴露给 IPMI，你需要用厂商的专用工具或者 Redfish 接口去读。这种情况下硬抠 ipmitool 是没意义的，换条路就行。
5.2 服务器开机风扇狂转的经典路径
“开机风扇狂转”是服务器最常见的故障现象之一，很多时候 CPU 还没起来、系统还没进 BIOS，风扇就已经满转。面对这件事不要慌，按顺序排查：
先看温度传感器是否正常。如果 CPU 温度传感器读数是 0 或者异常值，BMC 会认为温度失控，直接拉满风扇转速。常见原因是 CPU 没装好、散热器没压紧、传感器接触不良。
再看传感器状态和 SEL 事件：
ipmitool sel list | tail -50如果 SEL 里全是温度告警，优先查散热和硅脂；如果有电源相关的告警，优先查电源和背板供电。风扇狂转本身是 BMC 的自我保护，不是故障根因，一定要顺着告警事件往回找。
还有一种容易忽略的情况是风扇本身缺相或者转速反馈线断了。有些服务器风扇是 4 针接口，一根 PWM 控制线，一根转速反馈线，如果转速反馈没接到 BMC，BMC 会默认风扇异常，同样拉满转速。这时候可以看单个风扇传感器是不是只有某一个FANx异常，而不是全部狂转。如果是单风扇异常，检查接针是否松动、线有没有断。
另外，浪潮、戴尔等很多服务器在更换风扇、加装硬件后，首次上电默认全转速运行，然后 BMC 重新训练风扇策略，过几分钟才恢复。这属于正常现象，但需要在监控里做延迟告警，别一看到风扇狂转就半夜打电话。
5.3 排查思路速查表
以下是我这几年用 ipmitool 排查电源风扇问题时总结的一张速查表，遇到问题直接对着看：
| 现象 | 可能原因 | 优先检查项 | 排查命令 |
|---|---|---|---|
| 某风扇传感器无读数 | 风扇未插、接针松、SDR 未更新 | 物理接线、风扇供电 | ipmitool sensor list | grep FAN |
| 风扇全部高速运转 | 温度传感器异常、CPU 过热、BMC 策略 | 传感器读数、SEL 事件 | ipmitool sel list |
| 电源模块状态异常 | 电源进线松、模块故障、电源背板 | 状态位、亮灯情况 | ipmitool sdr list | grep -i ps |
| 功耗读数为 na | DCMI 不支持、权限不足 | 固件版本、账号权限 | ipmitool dcmi power reading |
| 远程连不上 BMC | 网络不通、623 端口被禁、IP 冲突 | 网口连通性、BMC 配置 | ping IP，ipmitool mc info |
| raw 命令无响应 | 平台不支持该 OEM 命令 | 厂商命令手册 | 检查命令返回码 |
| 风扇转速设置后重启恢复 | 手动模式未持久化 | 重新执行脚本 | 开机后重新设置 |
| 传感器显示 na 但状态 ok | 传感器未启用或读不到 | BIOS/BMC 设置 | ipmitool sensor list |
排查时的另一个原则是：先看 SEL，再看传感器。SEL 是 BMC 记录的历史事件，传感器当前值只是快照。很多间歇性故障，靠当前值根本看不出来，但 SEL 里早就有告警。养成定期导出 SEL 的习惯，比如每天凌晨存一份，对定位这类问题帮助极大。
5.4 脚本化时的几个实用经验
批量管理几百台服务器时，ipmitool 的坑会成倍放大。我整理几条典型经验供你参考：
登录超时和并发限制。BMC 本身的处理能力很有限，大批量同时执行 ipmitool 会导致超时。我通常用xargs -P控制并发数，一个 BMC 同时只允许十个以内的查询线程，超过就容易丢包。
密码安全管理。不要在命令行里直接明文写密码，也不要把密码放在脚本文件里提交到 Git。用环境变量、密钥管理工具，或者封装一个ipmitool_wrapper.sh，统一在里边处理认证信息，脚本只关心业务逻辑。
版本兼容性。老服务器配新版本 ipmitool 偶发协议兼容问题，如果某些服务器返回异常空结果，可以先降级 ipmitool 或者改用freeipmi工具对比验证，快速判断是工具问题还是硬件问题。
报警阈值要结合季节。数据中心温度随季节波动很大，冬天机房 18 度时风扇 3000 转很正常，夏天进风 35 度时 6000 转也可能很正常。别把风扇转速绝对值作为唯一报警依据，要用转速相对于温度基线的偏离来判断。比如同样 CPU 50 度，冬天风扇 4000 转，夏天风扇 8000 转，都是正常状态；但如果温度没变，风扇转速突然上涨或下跌，才需要关注。
我自己的习惯是：温度不变，风扇转速涨超过 20%，进入观察清单；电源模块温度比平时高 15 度以上，直接开票准备备件。这些阈值都不是来自厂商手册，而是看了一段时间历史数据后自己定的，比死阅读手册靠谱得多。
最后说两句
用 ipmitool 做电源和风扇监控这件事，刚开始会觉得命令又多又杂，传感器名字还挺绕，但真正把流程跑顺之后，你会发现它是服务器硬件可靠性里性价比最高的一环。带外管理天然不依赖操作系统，哪怕系统完全卡死，你照样能远程看到电源和风扇状态，这是 Agent 类监控替代不了的。
我个人的体会是，不要等机器出问题了再去学这些命令，而是在服务器刚上架、系统还没部署业务的时候，就把 BMC 地址配好、监控采集跑起来、SEL 定期备份做好。硬件故障从来毫无预兆，但 ipmitool 能帮你提前几周发现那些藏在传感器数据里的小异常，这个提前量，往往能救一台机器，也救一个加班的晚上。
