简介服务器常见故障是运维人员日常工作中最常面对的难题之一尤其在内存、电源模块、硬盘等硬件层面故障表现隐蔽且排查链路较长。这份docx文档面向服务器管理员、运维工程师及技术支持人员系统梳理了从故障现象观察到定位处理的全流程先通过环境灯、BMC日志、系统日志、dmesg日志、应用日志逐层排查再针对内存报错、电源模块亮红灯、硬盘RAID与非RAID状态下的异常识别等典型场景给出具体判断方法和处理建议。文档还补充了阵列卡、硬盘背板、CPU、阵列卡电池及文件系统只读等常见故障的解决思路并演示了Megacli等工具的实际输出案例便于读者对照手册快速上手。资源为1个docx文档大小约465KB内容精炼、可直接作为运维排错速查参考。已有209人学习下载对于正在搭建服务器维护体系或希望提升硬件故障应对能力的工程师而言是一份务实且易读的资料。1. 服务器故障排查从哪一步开始遇到服务器告警最常见的错误是一上来就重启或者只盯着某一个日志文件看。我在生产环境里处理过不少“假故障”和“真故障”最深的体会是排查顺序比排查动作更重要。正常路径应该是先看设备环境灯和 BMC 日志再翻系统日志、dmesg最后才看应用日志。环境灯能告诉你故障发生在硬件层还是系统层BMC 日志则把内存、电源、硬盘、主板的异常事件按时间记下来避免你被应用报错带偏。这套流程对刚接手服务器运维的新手来说是最快建立排查框架的起点对有经验的人来说也能帮你在多台机器同时告警时确定优先级。2. 硬件告警信号内存、电源与主板的 BMC 日志定位2.1 环境灯与 BMC 日志故障定位的第一现场服务器机箱上的环境灯或叫健康灯、告警灯颜色变化是硬件故障最直观的表现。不同品牌对告警灯的定义有差异但规律基本一致亮红色表示当前故障橙色表示预告警或非致命告警绿色为正常。有些品牌比如华为和 Dell 的部分机型可以通过单个内存槽位的指示灯直接指出故障内存位置而 HP 和 IBM 通常只给一个总告警需要进入 BMC 界面或通过命令行看具体部件。BMC 日志是硬件层面的“黑匣子”。它不依赖操作系统只要主板还通电就能记录。实际排查时我一般先用浏览器打开 BMC 管理地址看 SELSystem Event Log或事件日志。如果厂商提供了 CLI 工具也可以用命令导出# 常见做法用 ipmitool 读取 BMC 传感器和事件日志 ipmitool sel elist ipmitool sel list # 只看最近 10 条避免被历史信息淹没 ipmitool sel elist | tail -10参数说明sel elist输出全部事件包含事件 ID、时间戳、传感器类型和断言状态sel list格式更简洁。执行时注意时间戳是否与当前服务器时间一致因为 BMC 时钟漂移很常见后面做时间线分析时容易误判。如果服务器在机房通过环境灯颜色先判断大致部件再结合 BMC 日志中的传感器类型如Memory、Power Supply、Drive Slot精确定位能省去不少来回进机房的折腾。2.2 内存故障MCE 日志与 message 日志的配合内存故障的典型现象是系统运行缓慢、频繁死机或者开机时报错。除了 BMC 日志报内存事件如果系统配置了 MCEMachine Check Exception内核会把硬件错误记录到系统日志里。MCE 是 CPU 检测到硬件错误后触发的异常机制内存地址错误、总线错误都会通过它暴露出来。在/var/log/message里抓内存错误我习惯用下面的命令grep -i mce\|machine check\|memory error\|EDAC /var/log/message egrep -i error|failed|warning /var/log/message | grep -i memory逻辑说明第一条命令直接找关键事件类型第二条命令在系统错误里做二次过滤把内存相关记录筛出来。看到诸如mce: [Hardware Error]: Machine check events logged或EDAC MC0: UE这类日志时基本可以确认内存或内存控制器存在硬件问题。注意UE表示不可纠正错误CE表示可纠正错误。可纠正错误频繁出现时虽然系统暂时不宕机但内存颗粒已经不稳定应尽快安排更换。不同厂商 BMC 的内存报错字段差别很大我整理了一份对照品牌BMC 日志典型字段定位粒度HPMemory Error/DIMM#可精确到槽位DellECC Memory/Mem Reg 0x...可精确到槽位华为Memory Uncorrectable Error可精确到槽位IBMMemory Log/DIMM部分机型精确到槽位实际生产中如果内存处于未插满状态BMC 日志报错后不要急着拔插先在系统里执行dmidecode -t memory确认内存槽位对应关系避免拔错内存导致额外故障。2.3 电源模块与主板利用多部件告警交叉确认电源模块故障最容易判断电源指示灯亮红色或闪烁BMC 日志里会有Power Supply或PSU传感器告警。但需要注意电源故障不一定都是 PSU 本身坏了也可能是输入电压不稳、电源线松动或负载瞬间过高。我遇到过一次 Dell 服务器报 PSU 故障最后发现是机房配电柜的单一相电电压偏低导致两个电源模块同时进入保护状态。主板故障的隐蔽性更高。常见现象是无法开机、开机后无显示、健康灯告警BMC 日志里却只有System Board或Fault这类模糊事件。此时需要结合其他部件告警做交叉判断。比如 IBM 服务器主板故障时BMC 往往同时报 CPU、内存、PCIe 等多个部件异常这是因为主板上的管理控制器失联导致所有依赖它的传感器全部告警。HP 服务器则可能出现 BMC 页面多个红色告警但每个部件单独测试都正常的情况。对于这类模糊故障我的经验是先拔掉所有非必要部件如多余的硬盘、扩展卡只保留一颗 CPU、一根内存和系统盘看能否进入 BIOS。如果最小化配置下故障依旧再考虑主板或 CPU 问题如果能正常启动则逐个插回部件找到触发的设备。这个过程虽然原始但比直接换主板更能定位问题。3. 硬盘故障指示灯、RAID 状态与 megacli 的完整排查路径3.1 做过 RAID 与没做 RAID 的指示灯差异硬盘故障在服务器故障里占比最高而且告警形式最乱。先说指示灯。在配置 RAID 的场景下大多数阵列卡会控制硬盘指示灯红色表示故障橙色表示预测性故障即 S.M.A.R.T. 数据异常但还能用绿色表示正常。这个规则对 Dell、HP、华为的服务器基本通用。但没做 RAID 的硬盘指示灯逻辑就不可靠了。只接一块直通盘时硬盘不亮并不代表故障可能是机器死机或背板供电异常。我见过有运维根据“硬盘灯不亮”直接判定硬盘损坏结果换了一块新盘上去还是不亮最后发现是背板故障。所以对于非 RAID 硬盘指示灯只能作为参考不能作为判据。状态RAID 硬盘指示灯非 RAID 硬盘指示灯建议动作正常绿色可能亮或闪烁无需处理预告警橙色无法判断关注 S.M.A.R.T. 数据故障红色可能不亮进入系统确认准备更换3.2 挂载异常与 dmesg 报错怎么区分硬盘和系统问题当硬盘没做 RAID系统里挂载时报mount: special device /dev/slot12 does not exist说明设备节点消失了。这个提示背后可能有两种原因一是硬盘本身离线二是驱动器号对应关系错乱。此时先看内核日志dmesg | tail -50 dmesg | grep -i error\|fail\|disk\|sas\|scsi # 查看存储设备列表 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL逻辑说明dmesg打印内核环形缓冲区信息硬盘掉线、SAS 链路断开、SCSI 层报错都会在这里留下记录。如果看到I/O error、sas: task failed或end_device: not responding基本能确认硬盘或链路有问题。如果 dmesg 里完全干净那就要怀疑是 udev 设备名变化或系统盘符漂移用lsblk按实际盘符重新挂载即可。另外/var/log/message里如果反复出现SATA link down或EXT4-fs error说明文件系统层面已经感知到硬盘异常。这种情况下即使硬盘还能识别也必须尽快备份数据并把盘列入更换计划。3.3 megacli 输出字段精读Firmware State 与错误计数在配置了 LSI 系列阵列卡如 IBM M5110、Dell PERC 等的服务器上megacli是定位硬盘故障最有效的工具。以下是从实际故障机器上抓到的输出片段megacli -PDList -aALL # 关键字段输出示例 Enclosure Device ID: 252 Slot Number: 0 Device Id: 8 Firmware state: Failed Media Error Count: 134 Other Error Count: 22 Predictive Failure Count: 4 Last Predictive Failure Event Seq Number: 32313 PD Type: SAS Raw Size: 558.911 GB [0x45dd2fb0 Sectors] Coerced Size: 557.861 GB [0x45bb9000 Sectors] SAS Address(0): 0x5000c50068a4ef05 Inquiry Data: IBM-ESXSST9600205SS B55D6XR4MSZ01018B55D参数说明-PDList表示列出所有物理磁盘-aALL表示作用于所有阵列卡。输出里的Firmware state是磁盘状态的核心常见值有Online, Spun Up正常、Failed故障、Rebuild重建中、Hot Spare热备盘。Media Error Count是介质错误次数只要不为 0 就要警惕Predictive Failure Count表示预测性故障计数超过阈值说明 S.M.A.R.T. 已经预警。再看另一段输出Media Error Count: 10750且Firmware state: Online, Spun Up。这个盘表面状态正常但错误计数非常高说明盘片已经出现大量坏道。在 RAID 组中这种盘后续掉线的概率极大。处理时可以使用以下命令强制下线或定位物理槽位# 定位物理磁盘点亮磁盘指示灯 megacli -PdLocate -start -physdrv[252:0] -aALL # 停止定位灯 megacli -PdLocate -stop -physdrv[252:0] -aALL # 查看所有虚拟磁盘状态 megacli -LDInfo -LALL -aALL其中[252:0]是Enclosure Device ID:Slot Number的格式。执行PdLocate -start后对应槽位的硬盘指示灯会闪烁方便在机房里快速识别物理盘。注意阵列卡类型不同命令可能变为sas3ircu或storcli但字段含义类似。3.4 硬盘背板与阵列卡故障多块盘同时告警时别急着换盘如果同一条背板下的多块硬盘同时报错或megacli看到多块盘Firmware state: Failed这时候要冷静因为很可能不是盘坏了而是背板或阵列卡故障。背板故障的典型表现多块硬盘无法识别、指示灯全灭或全红BMC 日志里没有对应的硬盘个体报错。阵列卡故障的表现则可能是无法新建 RAID、已有 RAID 中多块盘同时掉线、硬盘顺序异常。遇到这种情况先做交叉验证把疑似故障盘插到另一条背板或另一台服务器的相同槽位如果盘正常识别则问题在背板/阵列卡如果盘依然报错则是盘本身问题。我曾经遇到一次 8 块盘全部“掉盘”最后发现是 RAID 卡电池耗尽导致写缓存策略异常重启后盘全部回来了。所以阵列卡电池BBU状态也要关注BMC 日志里的Battery #0x11 | Low | Asserted就是典型报错。4. 系统层故障文件系统只读、Grub 修复与 MBR 重建4.1 文件系统只读fsck 不是万能的服务器运行中突然出现Read only filesystem通常意味着文件系统检测到异常内核将挂载模式切换为只读以保护数据。最常见的原因是电源异常掉电、硬盘坏道或文件系统元数据损坏。在单用户模式或救援模式下执行修复# 先卸载分区避免文件系统被占用 umount /dev/sda1 # 强制检查并自动修复 fsck -y /dev/sda1-y表示对所有修复询问自动回答 yes。注意如果根分区变成只读无法直接卸载需要重启到 live CD 或 linux rescue 模式执行。执行前最好先备份分区表dd if/dev/sda of/root/mbr_backup bs512 count1。如果 fsck 执行后依旧报错且错误集中在同一个扇区区域那很可能是硬盘物理坏道需要更换硬盘。另外fsck只能修复文件系统结构问题不能修复磁盘介质问题。当系统日志里连续出现Buffer I/O error on device sda1时即使 fsck 能跑完后续也会反复出问题。此时应优先迁移数据把整块盘换掉而不是反复 fsck。4.2 Grub 故障从 rescue 模式到手动引导开机卡在GRUB命令行通常是 grub 配置文件损坏或 boot 分区修改失误。系统里如果存在 grub 配置备份可以从光盘引导进入 linux rescue 模式然后执行# 进入救援模式后先 chroot 到实际系统 chroot /mnt/sysimage # 恢复 grub 配置文件 cp /backup/grub.conf.bak /boot/grub/grub.conf # 重新安装 grub 到 MBR grub-install /dev/sda如果没有备份就需要在 grub 命令行手动引导。常见的手工引导序列# 查看 grub 所在分区 grub find /boot/grub/grub.conf (hd0,0) # 查看配置文件内容定位错误 grub cat (hd0,0)/boot/grub/grub.conf # 指定 boot 分区 grub root (hd0,0) # 指定内核与根分区 grub kernel /boot/vmlinuz-2.6.24-1.3194.fc7 ro rootLABEL/ # 指定 initrd 镜像 grub initrd /boot/initrd-2.6.24-1.3194.fc7.img # 启动 grub boot这里每一步都有讲究root (hd0,0)是告诉 grub 内核文件位于第一块硬盘的第一个分区对应 Linux 里的/dev/sda1kernel行的rootLABEL/指定根文件系统的挂载参数需要与 fstab 里的标签一致initrd加载必要的驱动模块。手动引导成功后进入系统第一件事就是修复 grub.conf 并重新执行grub-install避免下次重启再次卡住。4.3 MBR 故障Operating System not found开机提示Operating System not found和 Grub 卡住不同这说明 BIOS/UEFI 根本没有找到可启动的引导程序。最常见原因是系统盘故障或 MBR 损坏。如果之前做过 MBR 备份可以直接还原# 从 live 环境还原 MBR假设备份文件在 /backup 下 dd if/backup/mbr_backup of/dev/sda bs446 count1只还原 446 字节是把 MBR 里的引导代码部分写回不覆盖分区表。如果没备份可以尝试重新安装 grub# 进入 rescue 模式后 chroot /mnt/sysimage grub-install /dev/sda执行完成后重启。如果仍然找不到系统用fdisk -l或gdisk -l检查分区表是否存在。分区表丢失时无法通过 grub-install 修复只能按原分区结构重建或在备份中恢复。最坏的情况是系统盘物理故障需要联系厂商更换硬盘然后利用备份恢复系统。这里需要强调MBR 修复只是应急手段它无法修复硬盘坏道。如果dmesg里已经大量出现 I/O 错误修完 MBR 后系统能启动但后续数据仍可能持续损坏。遇到这种情况应立刻做数据备份并安排更换磁盘。5. 设备自动重启与死机的日志取证思路5.1 自动重启的分类硬件、双机心跳与应用层设备自动重启往往不是单一原因需要按层级排查。第一类是硬件触发比如电源波动、CPU 过热、内存不可纠正错误BMC 日志里会有Power Unit、Temperature、Memory告警。第二类是系统层面比如内核 panic、watchdog 超时、文件系统只读后服务无响应。第三类是高可用场景下的双机切换看似是服务器重启其实是心跳丢失后节点主动重启或切换。对于双机热备环境除了系统日志还要重点看心跳日志。常见错误是心跳线松动或 IP 冲突导致两个节点互相认为对方故障出现“脑裂”然后双方同时试图接管资源。分析时我会先看# 查看系统重启记录 last reboot | head -10 # 查看双机软件日志以 heartbeat 为例 grep -i heartbeat\|split brain\|takeover /var/log/ha-log5.2 message 与 dmesg 的快速过滤命令系统日志量很大时全量翻看效率极低。我一般用下面的命令做粗筛cat /var/log/message | egrep -i error|failed|warning|unknown|OOPS|panic|No|bad dmesg | egrep -i error|failed|warning|unknown|OOPS|panic|No|bad参数说明egrep -i忽略大小写同时匹配多个关键字。OOPS是内核线程出错的标记panic是内核致命错误出现这两个词基本可以判定为系统级崩溃。bad和No的范围较宽需要看上下文。只看匹配到的行还不够我通常会在匹配行前后各取 3 行观察事件链条egrep -i panic|oops /var/log/message | head -5 | cut -d -f1-3拿到时间戳后用grep -A3 -B3查看对应时间段的完整上下文。如果发现Out of memory: Kill process或者oom-killer说明是内存耗尽触发系统杀掉进程严重时导致假死和自动重启。5.3 死机的现场判断与重启决策死机时的现象通常是接显示器黑屏但电源灯亮所有硬盘灯不亮网络也 ping 不通。这种状态下系统可能已经处于硬件级别的 hang。先别急着按电源键用下面的顺序处理检查 BMC 页面是否还能访问。BMC 还能访问说明主板供电正常问题在 CPU 或内存。通过 BMC 的远程控制台发送 NMI 中断抓取内核堆栈# 使用 ipmitool 给目标机器发送 NMI触发内核崩溃转储 ipmitool -H bmc_ip -U user -P pass chassis status ipmitool -H bmc_ip -U user -P pass chassis power softNMI切换后系统可能会把/var/crash或/var/log/message里的堆栈信息记录下来结合crash工具或vmcore分析原因。如果 BMC 也无法访问说明管理控制器都失去了响应大概率是主板或电源板故障只能做硬件层面的强制重启。注意强制断电重启属于最后手段。重启前如果条件允许先通过串口或 BMC 截图保存现场。因为很多死机问题在重启后不会再出现等到下次发作时才能再次抓取日志。6. 故障时间线核对与阵列卡电池的隐性问题运维排障时最容易忽略的是时间戳的偏移。BMC 时钟、系统时钟和应用程序日志时钟经常不一致尤其是 NTP 配置不规范的机房。曾经遇到一台服务器BMC 日志显示 14:00 内存报错系统日志显示 14:30 才重启实际是 BMC 时钟慢了半小时导致排障方向全错。所以拿到日志后第一件事是对时。# 核对系统当前时间 date -R # 检查 NTP 状态 chronyc tracking ntpq -p如果发现系统时间被改成错误值先手动修正再检查/etc/chrony.conf或/etc/ntp.conf里的时间服务器配置。BMC 的时间也要与系统时间对齐多数厂商的 BMC 支持用 NTP 或命令行同步。时间戳对齐之后把 BMC 报错、系统日志重启时间、应用日志异常时间按顺序排列才能判断是硬件先坏导致系统崩溃还是应用先异常导致系统负载过高触发硬件告警。另一个隐蔽问题是阵列卡电池。很多运维只关注硬盘状态忽略了 BBUBattery Backup Unit低压告警。BBU 的作用是在断电时缓存 RAID 卡写缓存里的数据如果电池电量低或老化阵列卡会自动禁用写缓存导致写入性能骤降。更危险的是电池彻底失效后如果中途断电缓存数据可能全部丢失进而引发多块盘同时报错甚至 RAID 组崩溃。BMC 或阵列卡日志里的Battery #0x11 | Low | Asserted就是典型告警。检查与处理方式如下# 查看阵列卡电池状态 megacli -AdpBbuCmd -aALL关注输出中的Battery State和Charger Status。如果显示Low或Failed应更换电池模块。更换前先确认服务器支持热插拔电池如果不支持需要计划内维护时间。更换后执行充电初始化# 对 BBU 执行学习周期learn cycle重新校准容量 megacli -AdpBbuCmd -BbuLearn -aALL学习周期会把电池放电再充满期间写缓存可能被临时禁用建议在业务低峰期执行。这条命令做完后再观察Battery State: Optimal阵列卡会重新启用写缓存性能恢复。最后提一个我在生产环境里验证过多次的技巧当系统日志和 BMC 日志都找不到明确原因时把排查范围缩小到“最近一次变更”。服务器不会无缘无故重启几乎所有故障都能关联到硬件退化、配置修改或外部触发。对比last reboot与变更记录往往能缩短一半的排查时间。本文还有配套的精品资源点击获取