服务器硬件故障如何检测？内存、磁盘、电源与温度监控方法

服务器出问题时，表现往往很"玄学"：偶尔重启、业务莫名变慢、某个进程被杀死、文件读出来是乱的。这些现象背后，很多是内存、磁盘、电源或散热这类硬件在悄悄劣化。如果只盯着应用日志，很容易查错方向，浪费大量时间。

这篇文章给出一套系统化的硬件故障检测方法：内存怎么查错误、磁盘怎么用 SMART 和阵列告警判断健康、电源怎么通过带外管理看状态、温度和风扇怎么监控，以及怎么把这些检查接入监控和告警，做到问题发生前就发现苗头。文中命令覆盖 RHEL/CentOS/Rocky 与 Debian/Ubuntu 两套，具体设备支持情况以厂商为准。涉及格式化、写盘、清盘的操作都有数据丢失风险，执行前务必确认并做好备份。

硬件故障检测的整体思路

排查硬件问题，先分清楚两类信号：一类是硬件自己上报的错误，比如 ECC 报错、SMART 告警、电源故障事件，这类最可靠，应该优先看；另一类是间接表现，比如性能下降、随机重启，需要结合硬件信号去印证。

分层的检查顺序大致是：内存 → 磁盘 → 电源 → 温度/风扇 → 主板与其他。日常巡检和监控也应该覆盖这几层，并且尽量在带外（BMC/IPMI）和操作系统内同时采集，互为补充。

下面按部件展开。

内存：ECC、EDAC 与 MCE

内存故障的典型表现是随机崩溃、奇怪的计算错误、进程异常退出，有时能通过内核日志找到线索。前提是系统开启了 ECC 和 EDAC 驱动。

# 安装 EDAC 工具
sudo dnf install -y edac-utils   # RHEL/CentOS/Rocky
sudo apt install -y edac-utils   # Debian/Ubuntu

# 查看内存控制器的可纠正/不可纠正错误计数
sudo edac-util -v
# 直接读原始计数器（路径可能因平台不同）
cat /sys/devices/system/edac/mc/mc0/ce_count   # 可纠正错误累计
cat /sys/devices/system/edac/mc/mc0/ue_count   # 不可纠正错误累计

# 查看内核日志里的内存错误线索
dmesg | grep -i -E 'edac|ecc|mce|correctable|uncorrectable'
journalctl -k | grep -i -E 'edac|mce'

# 查看 MCE（机器检查异常）日志，mcelog 部分平台需要单独安装
sudo dnf install -y mcelog   # RHEL/CentOS/Rocky（老平台）
sudo apt install -y mcelog   # Debian/Ubuntu
sudo mcelog --client 2>/dev/null || sudo cat /var/log/mcelog 2>/dev/null

关注要点：ce_count 持续增长说明可纠正错误在反复发生，通常是内存颗粒老化、接触不良或散热不佳的前兆，应列入计划更换；ue_count 大于 0 说明出现了不可纠正错误，可能已经导致过崩溃或数据损坏，属于高优先级，应尽快排查并更换对应内存条。定位到具体插槽可以结合 EDAC 的 per-dimm 信息和 dmidecode 的插槽编号。

要确认某条内存是否真的健康，最彻底的方法是 memtest86：从 U 盘引导运行，脱离操作系统反复读写校验，能发现 ECC 日常监控看不到的早期故障。新机器上架前、怀疑内存问题时建议跑完整一轮。

# 安装 memtest86+（重启后在引导菜单选择）
sudo dnf install -y memtest86+   # RHEL/CentOS/Rocky（需对应仓库）
sudo apt install -y memtest86+   # Debian/Ubuntu
sudo update-grub
# 或从官方下载 ISO 制作独立启动盘后引导运行

磁盘：SMART、阵列告警与坏道检测

磁盘故障是服务器最常见的硬件问题之一，现代硬盘基本都支持 SMART（自我监测、分析与报告技术），是第一道防线。

# 安装 smartmontools
sudo dnf install -y smartmontools   # RHEL/CentOS/Rocky
sudo apt install -y smartmontools   # Debian/Ubuntu

# 查看整体健康状态
sudo smartctl -H /dev/sda

# 查看全部属性，重点看重映射扇区、待处理扇区、通电时间、温度
sudo smartctl -a /dev/sda
sudo smartctl -A /dev/sda | grep -Ei 'Reallocated|Pending|Uncorrectable|Temperature|Power_On'

# 查看设备信息与是否支持 SMART
sudo smartctl -i /dev/sda

# 发起短/长自检（后台运行，不中断业务）
sudo smartctl -t short /dev/sda
sudo smartctl -t long /dev/sda
sudo smartctl -l selftest /dev/sda   # 查看自检结果

判读要点：Reallocated_Sector_Ct（重映射扇区数）和 Current_Pending_Sector（待处理扇区数）大于 0 且持续增长，通常意味着盘在劣化，应尽快备份并计划更换；离线不可纠正扇区数（Offline_Uncorrectable）非零要高度警惕；温度长期偏高也会加速劣化。SMART 会给出 PASSED/FAILED 的总体判断，但很多情况下状态显示 PASSED，属性却已经在恶化，所以要养成看具体属性的习惯。

如果是接在 RAID 卡后面的盘，smartctl 需要指定设备类型：

# 通过 RAID 卡读取物理盘 SMART（编号因卡而异，先用 storcli 查到 device id）
sudo smartctl -a -d megaraid,0 /dev/sda
sudo ./storcli64 /c0 /eall /sall show      # 查看物理盘状态与槽位

阵列层面的告警同样重要。RAID 阵列降级或重建状态要第一时间发现：

# 软 RAID 状态
cat /proc/mdstat
sudo mdadm --detail /dev/md0

# LVM（配合 RAID 时）
sudo pvs; sudo vgs; sudo lvs

# ZFS 存储池健康
sudo zpool status -v

/proc/mdstat 里出现 [U_] 或 [U__] 这类带下划线的标记，说明有成员盘掉线，阵列已降级，必须尽快处理。ZFS 的 zpool status 显示 DEGRADED 或出现校验错误（CKSUM）也要立即关注。

坏道检测要特别小心。badblocks 的写测试会破坏磁盘上的所有数据，只能用于确认无用的盘或已备份的空盘：

# 只读测试，相对安全，但很慢（不写入，不破坏数据）
sudo badblocks -sv /dev/sdb

# 危险操作：写测试会清空整盘数据，务必确认盘上无数据且已备份！
sudo badblocks -wsv /dev/sdb

对在用数据盘，优先用只读模式或依赖 SMART 长自检，不要在业务盘上做破坏性写测试。

电源与整机：带外管理

电源、风扇、主板等状态主要靠带外管理（BMC/IPMI）获取，这也是服务器相比普通 PC 的一大优势：即使系统宕机，带外管理依然可用。

# 安装 ipmitool
sudo dnf install -y ipmitool   # RHEL/CentOS/Rocky
sudo apt install -y ipmitool   # Debian/Ubuntu

# 查看电源模块状态与冗余情况
sudo ipmitool sdr type "Power Supply"
sudo ipmitool sdr type "Power Unit"

# 查看机箱整体状态（含故障相关事件）
sudo ipmitool chassis status

# 查看系统事件日志（SEL），排查历史异常，这是排查偶发问题的关键
sudo ipmitool sel list | tail -50
sudo ipmitool sel elist | grep -i -E 'power|psu|fan|temp|memory|disk'

# 清空 SEL 前先导出备份（清空后历史记录不可恢复，谨慎操作）
sudo ipmitool sel save /tmp/sel_backup.txt

SEL（System Event Log）是诊断偶发故障的宝库。很多机器重启、告警的原因都记录在里面，比如某路电源掉过、某个风扇转速异常、温度超过阈值。排查问题前先导出 SEL 存档，再分析。

温度与风扇

温度和风扇转速直接反映散热是否正常，也是很多稳定性问题的根源。

# lm-sensors：查看各类温度传感器和风扇转速
sudo dnf install -y lm_sensors   # RHEL/CentOS/Rocky
sudo apt install -y lm_sensors   # Debian/Ubuntu
sudo sensors-detect --auto
sensors
watch -n 2 sensors               # 持续观察

# IPMI：查看温度与风扇传感器及阈值
sudo ipmitool sdr type Temperature
sudo ipmitool sdr type Fan
sudo ipmitool sensor list | grep -Ei 'temp|fan'

# 硬盘温度
sudo smartctl -A /dev/sda | grep -i temperature

# NVMe 温度
sudo dnf install -y nvme-cli
sudo nvme smart-log /dev/nvme0 | grep -i temperature

# 是否有因过热触发的降频
dmesg | grep -i -E 'thermal|throttl'

要重点关注进风温度（反映机柜冷却是否正常）、CPU/GPU 温度和硬盘温度。硬盘长期高于 45℃ 到 50℃ 就值得警惕，这些是经验阈值，具体以厂商规格为准。温度异常常常不是服务器本身的问题，而是机柜气流、盲板缺失或空调故障导致的，排查时要向上找原因。

命令清单汇总

接入监控与告警

上面的命令适合手工排查，但要真正防患于未然，必须做持续采集和告警。思路是把关键指标接入监控系统（如 Prometheus + node_exporter、Zabbix、Netdata 等），并设置合理阈值。

操作系统层面可以用采集脚本或现成的导出器：node_exporter 能采集温度、负载、磁盘等基础指标；smartctl_exporter 或 textfile collector 可以把 SMART 属性暴露出来；硬件层指标则通过 redfish/ipmi exporter 从带外管理抓取。至少应覆盖以下几类告警：

• 内存 ue_count > 0，或 ce_count 增长速率异常；
• 磁盘 SMART 出现重映射/待处理扇区增长，或预测性故障告警；
• RAID 阵列降级、重建中失败、ZFS DEGRADED 或校验错误；
• 电源模块故障、冗余丢失（只剩一路供电）；
• 温度超过阈值（进风、CPU、硬盘）、风扇转速异常或停转。

告警阈值要结合设备规格设置，宁可在劣化早期报出来，也不要等停机才发现。同时把这些数据保存一段时间用于趋势分析，能提前看出哪块盘、哪条内存正在走下坡路。

# 简单的巡检脚本示例：把关键信息汇总输出，便于每日检查或接入采集
#!/bin/bash
echo "== 内存 ECC 错误 =="
for f in /sys/devices/system/edac/mc/mc*/ce_count; do [ -f "$f" ] && echo "$f: $(cat $f)"; done
for f in /sys/devices/system/edac/mc/mc*/ue_count; do [ -f "$f" ] && echo "$f: $(cat $f)"; done
echo "== 磁盘健康 =="
for d in /dev/sd?; do echo "-- $d --"; sudo smartctl -H "$d" 2>/dev/null | grep -i result; done
echo "== 阵列 =="
cat /proc/mdstat 2>/dev/null
echo "== 电源 =="
sudo ipmitool sdr type "Power Supply" 2>/dev/null
echo "== 温度 =="
sensors 2>/dev/null | grep -Ei 'temp|fan' | head -20

脚本用 root 或 sudo 运行，建议通过 cron 定时执行并归档输出，或直接由监控系统的采集器调用。

常见问题

Q：SMART 显示 PASSED，是不是就没问题？
不一定。PASSED 只代表没触发总体失败条件，具体属性（重映射、待处理扇区、温度）可能在恶化。要看属性趋势，不能只看结论。

Q：内存 ce_count 增长要马上换吗？
不一定马上，但要认真对待。它说明内存在反复出错，应记录增长速率、排查散热和插槽接触，制定更换计划。若 ue_count 出现，则应尽快处理。

Q：badblocks 能对在用数据盘跑吗？
只读模式可以但很慢；写测试（-w）会破坏全部数据，绝对不能用在有数据的盘上。用之前确认清楚盘的内容并做好备份。

Q：怎么排查偶发重启？
先导出并分析 IPMI SEL 事件日志，再看内核日志里的 MCE、thermal、panic 记录。硬件层线索通常在带外日志里。

Q：没有带外管理能用这些方法吗？
大部分操作系统内的命令（EDAC、smartctl、sensors）仍可用，但电源、机箱事件等硬件级信息会缺失。带外管理是服务器运维的重要工具，建议优先选用支持的机型。

总结

• 硬件排障优先看硬件自己上报的信号：内存 ECC/EDAC、磁盘 SMART、电源事件、温度告警，再结合间接表现印证。
• 内存重点盯 ce_count 和 ue_count，磁盘重点盯重映射/待处理扇区和自检结果，阵列重点盯降级与校验错误，电源和机箱事件靠 IPMI SEL。
• 温度和进风温度是很多稳定性问题的根源，既要看服务器自身，也要向上排查机柜气流和空调。
• 手工排查之外，务必把关键指标接入监控并设置阈值告警，配合长期趋势分析，在劣化早期就介入。
• 涉及 badblocks 写测试、格式化、清空 SEL、更换内存/硬盘等操作都有数据丢失或断电风险，执行前先备份、确认设备无误，并遵守机房安全规程。