尧图网页设计 
简介这份PDF资料聚焦Linux/Unix服务器运维中的典型故障排查与修复面向有一定基础的运维工程师、系统管理员及备考相关认证的技术人员。内容以真实案例为主线涵盖RAID1数据分区挂载异常、依赖库丢失导致root无法登录、GRUB分区误删后的双系统引导修复、硬盘移除引发紧急模式以及FreeBSD jail虚拟机/usr目录被写满等场景并延伸出fstab配置、fsck检查、单用户模式、网络引导与MBR修复等实用排错思路。资源包共1个PDF文件约367KB轻量便携适合随时查阅与复盘。目前已有92人学习虽体量不大但案例典型、步骤具体能帮助读者理解故障成因、掌握应急恢复流程并积累日常巡检与高可用模拟实验的注意事项提升线上环境的排障信心与操作谨慎度。1. 从一台还能 ping 通的 Linux 服务器说起故障篇到底在讲什么凌晨两点,监控告警响了,一台跑着业务的 Linux 服务器 SSH 连不上,但ping内网地址居然还通。这种半死不活的状态,比直接宕机更让人抓狂——因为ping显示一般故障,不代表系统健康,只代表 ICMP 那一层还活着。所谓明明白白你的 Linux 服务器,核心不是背命令,而是建立一套从硬件、内核、网络到应用层的分层排查思路,让每一次故障都有迹可循,而不是靠重启碰运气。这篇内容面向的是每天和服务器打交道的运维、后端和嵌入式 Linux 工程师。它解决的不是Linux 怎么装这种入门问题,而是当服务器出现硬盘掉盘、阵列卡告警、进程假死、网络时通时断、系统盘符对不上这些真实故障时,你该怎么一步步定位。下面按先分层理解 → 再动手排查 → 最后避坑的顺序展开,每一层都给出可复现的命令和判断依据,新手能照着敲,熟手能对照边界参数。2. 故障分层模型为什么你的第一反应总是错的2.1 从硬件到应用的五层排查顺序很多人一遇到服务器故障,第一反应是reboot,这是最省事也最危险的做法。重启会清掉内存里的现场,日志可能还没落盘,阵列卡缓存里的报错也可能被覆盖。正确的顺序是从下往上:硬件层(电源、内存、磁盘、阵列卡)、内核层(dmesg、内核 panic、驱动)、系统层(文件系统、挂载、进程)、网络层(网卡、路由、防火墙)、应用层(服务进程、端口、配置)。这个顺序的道理很简单:上层故障往往是下层问题的表现。比如应用连不上数据库,可能是网络层 iptables 拦了,也可能是系统层磁盘满了导致数据库写不进去,还可能是硬件层某块盘掉了触发 RAID 降级。如果你直接从应用层查,很容易在错误的方向上耗掉半小时。判断当前卡在哪一层,最快的入口是dmesg -T。它带时间戳输出内核环形缓冲区,硬件报错、驱动加载失败、磁盘 I/O 错误、OOM killer 触发都会在这里留痕。我一般排查任何服务器故障,第一条命令就是它。# -T 把内核时间戳转成可读时间, -l 按级别过滤 err/warn dmesg -T --levelerr,warn | tail -50 # 关注关键词: I/O error, medium error, RAID, megaraid, mpt3sas, OOM, call trace逻辑说明:内核日志是硬件和驱动问题的黑匣子,优先级高于任何应用日志。参数上--levelerr,warn能过滤掉大量 info 噪音,tail -50先看最近的。如果这里出现I/O error或medium error,基本可以锁定磁盘或链路问题,不用再往上查应用。2.2 阵列卡与硬盘:盘符对不上时怎么定位热搜里频繁出现lsi-9361-8i阵列卡和怎么定位在系统下的盘符,这是硬件层最典型的痛点。RAID 卡把物理盘抽象成逻辑卷,操作系统看到的是/dev/sdb这种逻辑盘,而物理槽位号(Slot)和系统盘符之间没有直接对应关系。当阵列卡报某块物理盘 pre-fail(预故障)时,你得先知道它是哪个槽,再确认它对应系统里哪个设备。常见做法是先用厂商工具查物理盘状态,再用lsblk和smartctl交叉验证。以 LSI/Broadcom 的 storcli 为例:# 查看所有物理盘状态, EID:Slt 是机箱号和槽位号 storcli /c0/eall/sall show # 输出里 State 列出现 UGood(正常) / UBad(故障) / Rbld(重建中) # 查看某块盘的详细错误计数 storcli /c0/e252/s3 show all | grep -i error逻辑说明:/c0是控制器 0,eall/sall表示所有机箱所有槽位。拿到槽位号后,再对照系统盘符:# 列出块设备及序列号, 用序列号跟阵列卡里的 WWN 对齐 lsblk -o NAME,SIZE,SERIAL,TYPE,MOUNTPOINT # 直接读某块盘的 SMART 健康信息 smartctl -a -d megaraid,3 /dev/sda参数说明:-d megaraid,3里的3是阵列卡给这块物理盘的 Device ID,不是系统盘符,必须先用 storcli 查到。这一步是很多人翻车的地方——直接对/dev/sdb跑 smartctl,读到的是逻辑卷的健康状态,不是那块预故障物理盘的。硬盘做 RAID0 时尤其要注意,RAID0 没有冗余,任何一块盘 pre-fail 都意味着数据随时可能全丢,发现预故障必须第一时间备份而不是等它彻底坏。3. 系统层与网络层:那些看起来正常的假象3.1 进程假死与 D 状态:为什么 kill -9 也杀不掉系统层最容易被误判的是进程状态。一个进程ps看还在,但服务不响应,kill -9也杀不掉,这通常是 D 状态(不可中断睡眠)。D 状态意味着进程卡在内核的系统调用里,多半是在等 I/O——磁盘、NFS、或者挂载的 NAS 存储。热搜里linux 挂载 nas 存储相关的故障,十有八九是 NFS 服务端无响应,导致客户端进程全部卡在 D 状态。# 找出所有 D 状态进程 ps -eo pid,stat,wchan:20,cmd | awk $2 ~ /D/ # 查看进程卡在哪个内核函数 cat /proc/PID/stack # 查看 NFS 挂载状态, 是否有 hard 挂载导致无法中断 mount | grep nfs逻辑说明:wchan列显示进程正在等待的内核函数,/proc/PID/stack能看到更精确的调用栈。如果发现大量进程卡在nfs_开头的函数上,基本可以确认是 NFS 问题。参数上,hard挂载的 NFS 在服务端失联时会无限重试,进程无法被 kill,这是设计行为不是 bug。解决办法是改用soft挂载加timeo超时,或者先恢复 NFS 服务端。提示:生产环境挂载 NFS 建议用soft,timeo100,retrans3,避免服务端抖动导致客户端大面积 D 状态。但soft在写入时可能返回错误,数据库类场景要谨慎评估。3.2 ping 通但服务不通:网络层排查的四个检查点ping显示一般故障、ping内网通但 SSH 连不上,这类问题在网络层。ICMP 通只说明 IP 层可达,不代表 TCP 端口开放。排查顺序是:网卡链路状态 → IP 和路由 → 防火墙规则 → 目标端口监听。# 1. 网卡物理链路和错误计数 ip -s link show eth0 # 2. 路由表, 确认默认网关和到目标网段的路由 ip route get 10.10.8.149 # 3. 防火墙规则, 注意 iptables 和 firewalld 可能同时存在 iptables -L -n -v --line-numbers # 4. 目标端口是否监听 ss -tlnp | grep :22逻辑说明:ip -s link的 RX/TX errors 和 dropped 计数能看出物理层是否有丢包。ip route get直接告诉你到目标地址会走哪个网卡和网关,比看整张路由表快。防火墙这块,iptables -L -n -v的-v会显示每条规则的匹配包数,如果某条 DROP 规则计数在涨,就是它拦的。ss -tlnp确认服务本身有没有监听端口,如果没监听,问题就不在防火墙而在服务本身。热搜里windows2016 服务器入站出站策略开放指定端口和ping 出现一般故障经常一起出现,本质是同一类问题:网络策略把 ICMP 或目标端口拦了。Linux 侧对应的是 iptables/firewalld,Windows 侧是高级防火墙,排查思路一致——先确认链路,再确认策略。4. 避坑与常见问题:那些年我踩过的排查陷阱4.1 现象:重启后阵列卡报错消失,以为修好了原因:重启清空了阵列卡的事件日志和内核环形缓冲区,预故障的物理盘可能暂时恢复响应,但 SMART 里的重映射扇区计数和 pending sector 不会因为重启归零。这是典型的后悔药没得吃——等它再次报错时,可能已经从 pre-fail 变成 failed。解决:任何硬件告警,重启前先storcli /c0/eall/sall show all /tmp/raid_before_reboot.log,把现场存下来。重启后对比 SMART 属性,重点看Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable三个值,只要有一个在涨,盘就该换。4.2 现象:df 显示磁盘没满,但服务报no space left on device原因:inode 耗尽,或者有进程持有已删除文件的句柄。df -h看的是块使用率,df -i才看 inode。大量小文件(比如 session 文件、日志碎片)会把 inode 用光,块还有空间但无法创建新文件。另一种情况是rm删了大文件,但进程还开着句柄,空间不释放。解决:先df -i确认 inode,再lsof | grep deleted找持有已删除文件的进程,重启该进程或 /proc/PID/fd/FD清空句柄。4.3 现象:ping 内网通,但 SSH 连接超时,防火墙规则看着是空的原因:firewalld 和 iptables 可能同时运行,iptables -L看到的是 iptables 自己的链,而 firewalld 用的是 nftables 后端,规则不在 iptables 里显示。或者 SELinux 拦了端口绑定。解决:firewall-cmd --list-all看 firewalld 规则,nft list ruleset看 nftables,getenforce确认 SELinux 状态。三个都查一遍再下结论。4.4 现象:RAID0 一块盘 pre-fail,想热插拔换盘原因:RAID0 没有冗余,拔掉任何一块盘,整个逻辑卷立即失效,数据全丢。热插拔只对 RAID1/5/6/10 这类有冗余的阵列有意义。解决:RAID0 遇到预故障,唯一正确操作是立即停机备份数据,然后整体重建。不要幻想在线换盘,RAID0 没有重建这回事。4.5 现象:系统盘符从 /dev/sda 变成 /dev/sdb,启动失败原因:服务器加了新硬盘或改了阵列卡配置,内核枚举顺序变了。用/dev/sdX写死在 fstab 或启动参数里,顺序一变就挂。解决:改用 UUID 或 LABEL 挂载。blkid查 UUID,/etc/fstab里用UUIDxxxx替代设备名。启动参数里的 root 设备同理,用rootUUIDxxxx。5. 把排查变成习惯:一套可复用的故障快照脚本排查能力最终要沉淀成流程,而不是每次靠记忆。我一般会在每台服务器上放一个故障快照脚本,出问题时先跑一遍,把现场固化下来,再慢慢分析。这样即使后面重启了,证据还在。#!/bin/bash # fault_snapshot.sh - 一键收集 Linux 服务器故障现场 SNAP_DIR/var/log/fault_$(date %Y%m%d_%H%M%S) mkdir -p $SNAP_DIR # 硬件与内核层 dmesg -T $SNAP_DIR/dmesg.log 21 smartctl -a /dev/sda $SNAP_DIR/smart_sda.log 21 storcli /c0/eall/sall show all $SNAP_DIR/raid.log 21 # 系统层 ps -eo pid,ppid,stat,wchan:20,cmd $SNAP_DIR/ps.log 21 df -h $SNAP_DIR/df.log 21 df -i $SNAP_DIR/df_inode.log 21 free -m $SNAP_DIR/mem.log 21 cat /proc/loadavg $SNAP_DIR/loadavg.log 21 # 网络层 ip -s link $SNAP_DIR/iplink.log 21 ip route $SNAP_DIR/route.log 21 ss -tlnp $SNAP_DIR/ss.log 21 iptables -L -n -v $SNAP_DIR/iptables.log 21 firewall-cmd --list-all $SNAP_DIR/firewalld.log 21 # 打包 tar czf $SNAP_DIR.tar.gz -C $(dirname $SNAP_DIR) $(basename $SNAP_DIR) echo 快照已保存: $SNAP_DIR.tar.gz逻辑说明:脚本按硬件、系统、网络三层分组收集,每类输出到独立文件,方便后续 grep。dmesg -T带时间戳,smartctl -a拿完整 SMART 属性,storcli show all拿阵列卡完整状态。ps里的wchan是排查 D 状态的关键列。最后打包成一个 tar.gz,方便传到分析机。参数上要注意:smartctl对阵列卡后面的物理盘需要-d megaraid,N,脚本里对/dev/sda直接跑只能拿到逻辑卷信息,实际使用时要把 N 替换成 storcli 查到的 Device ID。storcli路径可能因版本不同在/opt/MegaRAID/storcli/下,脚本里最好用command -v storcli先判断存在性。这套脚本的价值不在于命令多高级,而在于它强制你把先取证再动手变成肌肉记忆。我见过太多人一上来就重启,结果问题复现不了,只能等下次再炸。养成先跑快照的习惯后,你会发现大部分故障其实在 dmesg 和 SMART 里早就写了答案,只是之前没人去看。最后说个我自己的教训:早年有台服务器反复掉盘,我每次都换盘了事,直到第三次才想起来对比三次的 SMART 日志,发现是背板供电不稳导致多块盘同时报错,换盘根本没用。从那以后,任何重复故障,我第一件事就是翻历史快照找规律,而不是急着换硬件。希望帮到你。本文还有配套的精品资源点击获取 Linux服务器故障排查：从ping通到SSH不通的分层定位与实战
简介这份PDF资料聚焦Linux/Unix服务器运维中的典型故障排查与修复面向有一定基础的运维工程师、系统管理员及备考相关认证的技术人员。内容以真实案例为主线涵盖RAID1数据分区挂载异常、依赖库丢失导致root无法登录、GRUB分区误删后的双系统引导修复、硬盘移除引发紧急模式以及FreeBSD jail虚拟机/usr目录被写满等场景并延伸出fstab配置、fsck检查、单用户模式、网络引导与MBR修复等实用排错思路。资源包共1个PDF文件约367KB轻量便携适合随时查阅与复盘。目前已有92人学习虽体量不大但案例典型、步骤具体能帮助读者理解故障成因、掌握应急恢复流程并积累日常巡检与高可用模拟实验的注意事项提升线上环境的排障信心与操作谨慎度。1. 从一台还能 ping 通的 Linux 服务器说起故障篇到底在讲什么凌晨两点,监控告警响了,一台跑着业务的 Linux 服务器 SSH 连不上,但ping内网地址居然还通。这种半死不活的状态,比直接宕机更让人抓狂——因为ping显示一般故障,不代表系统健康,只代表 ICMP 那一层还活着。所谓明明白白你的 Linux 服务器,核心不是背命令,而是建立一套从硬件、内核、网络到应用层的分层排查思路,让每一次故障都有迹可循,而不是靠重启碰运气。这篇内容面向的是每天和服务器打交道的运维、后端和嵌入式 Linux 工程师。它解决的不是Linux 怎么装这种入门问题,而是当服务器出现硬盘掉盘、阵列卡告警、进程假死、网络时通时断、系统盘符对不上这些真实故障时,你该怎么一步步定位。下面按先分层理解 → 再动手排查 → 最后避坑的顺序展开,每一层都给出可复现的命令和判断依据,新手能照着敲,熟手能对照边界参数。2. 故障分层模型为什么你的第一反应总是错的2.1 从硬件到应用的五层排查顺序很多人一遇到服务器故障,第一反应是reboot,这是最省事也最危险的做法。重启会清掉内存里的现场,日志可能还没落盘,阵列卡缓存里的报错也可能被覆盖。正确的顺序是从下往上:硬件层(电源、内存、磁盘、阵列卡)、内核层(dmesg、内核 panic、驱动)、系统层(文件系统、挂载、进程)、网络层(网卡、路由、防火墙)、应用层(服务进程、端口、配置)。这个顺序的道理很简单:上层故障往往是下层问题的表现。比如应用连不上数据库,可能是网络层 iptables 拦了,也可能是系统层磁盘满了导致数据库写不进去,还可能是硬件层某块盘掉了触发 RAID 降级。如果你直接从应用层查,很容易在错误的方向上耗掉半小时。判断当前卡在哪一层,最快的入口是dmesg -T。它带时间戳输出内核环形缓冲区,硬件报错、驱动加载失败、磁盘 I/O 错误、OOM killer 触发都会在这里留痕。我一般排查任何服务器故障,第一条命令就是它。# -T 把内核时间戳转成可读时间, -l 按级别过滤 err/warn dmesg -T --levelerr,warn | tail -50 # 关注关键词: I/O error, medium error, RAID, megaraid, mpt3sas, OOM, call trace逻辑说明:内核日志是硬件和驱动问题的黑匣子,优先级高于任何应用日志。参数上--levelerr,warn能过滤掉大量 info 噪音,tail -50先看最近的。如果这里出现I/O error或medium error,基本可以锁定磁盘或链路问题,不用再往上查应用。2.2 阵列卡与硬盘:盘符对不上时怎么定位热搜里频繁出现lsi-9361-8i阵列卡和怎么定位在系统下的盘符,这是硬件层最典型的痛点。RAID 卡把物理盘抽象成逻辑卷,操作系统看到的是/dev/sdb这种逻辑盘,而物理槽位号(Slot)和系统盘符之间没有直接对应关系。当阵列卡报某块物理盘 pre-fail(预故障)时,你得先知道它是哪个槽,再确认它对应系统里哪个设备。常见做法是先用厂商工具查物理盘状态,再用lsblk和smartctl交叉验证。以 LSI/Broadcom 的 storcli 为例:# 查看所有物理盘状态, EID:Slt 是机箱号和槽位号 storcli /c0/eall/sall show # 输出里 State 列出现 UGood(正常) / UBad(故障) / Rbld(重建中) # 查看某块盘的详细错误计数 storcli /c0/e252/s3 show all | grep -i error逻辑说明:/c0是控制器 0,eall/sall表示所有机箱所有槽位。拿到槽位号后,再对照系统盘符:# 列出块设备及序列号, 用序列号跟阵列卡里的 WWN 对齐 lsblk -o NAME,SIZE,SERIAL,TYPE,MOUNTPOINT # 直接读某块盘的 SMART 健康信息 smartctl -a -d megaraid,3 /dev/sda参数说明:-d megaraid,3里的3是阵列卡给这块物理盘的 Device ID,不是系统盘符,必须先用 storcli 查到。这一步是很多人翻车的地方——直接对/dev/sdb跑 smartctl,读到的是逻辑卷的健康状态,不是那块预故障物理盘的。硬盘做 RAID0 时尤其要注意,RAID0 没有冗余,任何一块盘 pre-fail 都意味着数据随时可能全丢,发现预故障必须第一时间备份而不是等它彻底坏。3. 系统层与网络层:那些看起来正常的假象3.1 进程假死与 D 状态:为什么 kill -9 也杀不掉系统层最容易被误判的是进程状态。一个进程ps看还在,但服务不响应,kill -9也杀不掉,这通常是 D 状态(不可中断睡眠)。D 状态意味着进程卡在内核的系统调用里,多半是在等 I/O——磁盘、NFS、或者挂载的 NAS 存储。热搜里linux 挂载 nas 存储相关的故障,十有八九是 NFS 服务端无响应,导致客户端进程全部卡在 D 状态。# 找出所有 D 状态进程 ps -eo pid,stat,wchan:20,cmd | awk $2 ~ /D/ # 查看进程卡在哪个内核函数 cat /proc/PID/stack # 查看 NFS 挂载状态, 是否有 hard 挂载导致无法中断 mount | grep nfs逻辑说明:wchan列显示进程正在等待的内核函数,/proc/PID/stack能看到更精确的调用栈。如果发现大量进程卡在nfs_开头的函数上,基本可以确认是 NFS 问题。参数上,hard挂载的 NFS 在服务端失联时会无限重试,进程无法被 kill,这是设计行为不是 bug。解决办法是改用soft挂载加timeo超时,或者先恢复 NFS 服务端。提示:生产环境挂载 NFS 建议用soft,timeo100,retrans3,避免服务端抖动导致客户端大面积 D 状态。但soft在写入时可能返回错误,数据库类场景要谨慎评估。3.2 ping 通但服务不通:网络层排查的四个检查点ping显示一般故障、ping内网通但 SSH 连不上,这类问题在网络层。ICMP 通只说明 IP 层可达,不代表 TCP 端口开放。排查顺序是:网卡链路状态 → IP 和路由 → 防火墙规则 → 目标端口监听。# 1. 网卡物理链路和错误计数 ip -s link show eth0 # 2. 路由表, 确认默认网关和到目标网段的路由 ip route get 10.10.8.149 # 3. 防火墙规则, 注意 iptables 和 firewalld 可能同时存在 iptables -L -n -v --line-numbers # 4. 目标端口是否监听 ss -tlnp | grep :22逻辑说明:ip -s link的 RX/TX errors 和 dropped 计数能看出物理层是否有丢包。ip route get直接告诉你到目标地址会走哪个网卡和网关,比看整张路由表快。防火墙这块,iptables -L -n -v的-v会显示每条规则的匹配包数,如果某条 DROP 规则计数在涨,就是它拦的。ss -tlnp确认服务本身有没有监听端口,如果没监听,问题就不在防火墙而在服务本身。热搜里windows2016 服务器入站出站策略开放指定端口和ping 出现一般故障经常一起出现,本质是同一类问题:网络策略把 ICMP 或目标端口拦了。Linux 侧对应的是 iptables/firewalld,Windows 侧是高级防火墙,排查思路一致——先确认链路,再确认策略。4. 避坑与常见问题:那些年我踩过的排查陷阱4.1 现象:重启后阵列卡报错消失,以为修好了原因:重启清空了阵列卡的事件日志和内核环形缓冲区,预故障的物理盘可能暂时恢复响应,但 SMART 里的重映射扇区计数和 pending sector 不会因为重启归零。这是典型的后悔药没得吃——等它再次报错时,可能已经从 pre-fail 变成 failed。解决:任何硬件告警,重启前先storcli /c0/eall/sall show all /tmp/raid_before_reboot.log,把现场存下来。重启后对比 SMART 属性,重点看Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable三个值,只要有一个在涨,盘就该换。4.2 现象:df 显示磁盘没满,但服务报no space left on device原因:inode 耗尽,或者有进程持有已删除文件的句柄。df -h看的是块使用率,df -i才看 inode。大量小文件(比如 session 文件、日志碎片)会把 inode 用光,块还有空间但无法创建新文件。另一种情况是rm删了大文件,但进程还开着句柄,空间不释放。解决:先df -i确认 inode,再lsof | grep deleted找持有已删除文件的进程,重启该进程或 /proc/PID/fd/FD清空句柄。4.3 现象:ping 内网通,但 SSH 连接超时,防火墙规则看着是空的原因:firewalld 和 iptables 可能同时运行,iptables -L看到的是 iptables 自己的链,而 firewalld 用的是 nftables 后端,规则不在 iptables 里显示。或者 SELinux 拦了端口绑定。解决:firewall-cmd --list-all看 firewalld 规则,nft list ruleset看 nftables,getenforce确认 SELinux 状态。三个都查一遍再下结论。4.4 现象:RAID0 一块盘 pre-fail,想热插拔换盘原因:RAID0 没有冗余,拔掉任何一块盘,整个逻辑卷立即失效,数据全丢。热插拔只对 RAID1/5/6/10 这类有冗余的阵列有意义。解决:RAID0 遇到预故障,唯一正确操作是立即停机备份数据,然后整体重建。不要幻想在线换盘,RAID0 没有重建这回事。4.5 现象:系统盘符从 /dev/sda 变成 /dev/sdb,启动失败原因:服务器加了新硬盘或改了阵列卡配置,内核枚举顺序变了。用/dev/sdX写死在 fstab 或启动参数里,顺序一变就挂。解决:改用 UUID 或 LABEL 挂载。blkid查 UUID,/etc/fstab里用UUIDxxxx替代设备名。启动参数里的 root 设备同理,用rootUUIDxxxx。5. 把排查变成习惯:一套可复用的故障快照脚本排查能力最终要沉淀成流程,而不是每次靠记忆。我一般会在每台服务器上放一个故障快照脚本,出问题时先跑一遍,把现场固化下来,再慢慢分析。这样即使后面重启了,证据还在。#!/bin/bash # fault_snapshot.sh - 一键收集 Linux 服务器故障现场 SNAP_DIR/var/log/fault_$(date %Y%m%d_%H%M%S) mkdir -p $SNAP_DIR # 硬件与内核层 dmesg -T $SNAP_DIR/dmesg.log 21 smartctl -a /dev/sda $SNAP_DIR/smart_sda.log 21 storcli /c0/eall/sall show all $SNAP_DIR/raid.log 21 # 系统层 ps -eo pid,ppid,stat,wchan:20,cmd $SNAP_DIR/ps.log 21 df -h $SNAP_DIR/df.log 21 df -i $SNAP_DIR/df_inode.log 21 free -m $SNAP_DIR/mem.log 21 cat /proc/loadavg $SNAP_DIR/loadavg.log 21 # 网络层 ip -s link $SNAP_DIR/iplink.log 21 ip route $SNAP_DIR/route.log 21 ss -tlnp $SNAP_DIR/ss.log 21 iptables -L -n -v $SNAP_DIR/iptables.log 21 firewall-cmd --list-all $SNAP_DIR/firewalld.log 21 # 打包 tar czf $SNAP_DIR.tar.gz -C $(dirname $SNAP_DIR) $(basename $SNAP_DIR) echo 快照已保存: $SNAP_DIR.tar.gz逻辑说明:脚本按硬件、系统、网络三层分组收集,每类输出到独立文件,方便后续 grep。dmesg -T带时间戳,smartctl -a拿完整 SMART 属性,storcli show all拿阵列卡完整状态。ps里的wchan是排查 D 状态的关键列。最后打包成一个 tar.gz,方便传到分析机。参数上要注意:smartctl对阵列卡后面的物理盘需要-d megaraid,N,脚本里对/dev/sda直接跑只能拿到逻辑卷信息,实际使用时要把 N 替换成 storcli 查到的 Device ID。storcli路径可能因版本不同在/opt/MegaRAID/storcli/下,脚本里最好用command -v storcli先判断存在性。这套脚本的价值不在于命令多高级,而在于它强制你把先取证再动手变成肌肉记忆。我见过太多人一上来就重启,结果问题复现不了,只能等下次再炸。养成先跑快照的习惯后,你会发现大部分故障其实在 dmesg 和 SMART 里早就写了答案,只是之前没人去看。最后说个我自己的教训:早年有台服务器反复掉盘,我每次都换盘了事,直到第三次才想起来对比三次的 SMART 日志,发现是背板供电不稳导致多块盘同时报错,换盘根本没用。从那以后,任何重复故障,我第一件事就是翻历史快照找规律,而不是急着换硬件。希望帮到你。本文还有配套的精品资源点击获取