Linux服务器故障排查：CPU、内存、磁盘IO问题定位与避坑指南

简介：这是一份面向Linux/Unix运维人员的故障排查经验合集，内容源自真实服务器维护场景，聚焦磁盘挂载异常、GRUB引导丢失、/etc/fstab配置错误、依赖库缺失导致无法登录、jail虚拟机存储占满等典型问题。资源共1个PDF文件，大小367KB，便于离线阅读，已有92人学习。文档采用故障一至五的案例形式，每个案例均给出问题现象、排查思路和具体命令，如fsck、mount、spfdisk/diskgen等，同时补充了RAID数据分区保护、网络引导修复、Nagios报警应对等实用经验，结尾还整理了服务器硬件巡检、机房环境控制等注意事项，适合初中级运维人员快速定位和解决服务问题，也可作为日常排障笔记参考。

1. 明明白白你的linux服务器-故障篇[收集].pdf：一份排障地图，不是命令手册

凌晨两点，监控平台的告警电话把你从床上拽起来：load average 23，接口超时率飙升。你 ssh 上去，top 一按，满屏看不懂的内核线程和 D 状态进程，手边那堆 linux 常用命令笔记翻到第八页还没找到对应条目。这时候你才明白，服务器故障排查最缺的不是命令手册，而是一份把现象翻译成操作顺序的故障篇。

这类标着“明明白白你的linux服务器-故障篇[收集]”的 PDF，本质上是运维老手平时攒下来的排障笔记合集：一个故障现象、一段日志截图、几条定位命令、一组内核参数，最后附上踩坑过程。它不教你从头学 Linux，而是告诉你服务器在什么时候会出问题、出问题先看哪、看完怎么做。适合三类人：刚上手服务器运维、遇到故障只会重启的开发者，以及想把自己的排查流程固化成清单的 SRE。下面我按自己真实的排障习惯，把这份资料里最值得照做的部分拆开讲。

2. 故障排查的顺序感：先看现象，再找证据，最后动配置

新手最容易犯的错，是看到 load 高就猜“内存不够”，看到端口不通就怀疑防火墙，然后直接改配置。改完发现没用，再回头查日志，时间白花，现场也被自己弄脏了。这类故障篇资料之所以有用，是因为它在每个案例里都强调同一个顺序：先记录当前状态，再取日志证据，然后用工具定位到具体进程或资源，最后才动配置。

这套顺序在服务器集群环境里更关键。几十台机器同时报警时，你不可能每台都登录进去猜一遍，必须先固定现场、拿到证据，再决定是哪一类问题、需要批量处理还是单点处理。顺序一旦反了，轻则多花两小时，重则一台机器上的误操作被脚本批量放大，连回滚都费劲。

2.1 三句话锁定主机状态：uptime、free、df 的读数边界

我接手一台服务器，无论报什么警，第一件事永远是跑三条命令记录快照：uptime、free -h、df -hT。它们分别回答三个最基础的问题：CPU 队列和负载、内存余量、存储余量。网上那些 linux 常用命令大全会告诉你每条命令有什么选项，但不会告诉你读数的边界在哪，这就是故障篇和命令手册的差别。

uptime输出里的 1、5、15 分钟三个 load 值，不能只看第一个。1 分钟高是瞬时压力，15 分钟也高才是长期问题；反过来，1 分钟正常但 15 分钟高，说明系统刚恢复没太久。判断过载与否，要把 load 和 CPU 核数对比：四核机器 load 长期高于 4，队列已经在堆积。free -h里真正要盯的是 available 列，不是 free 列。Linux 会把空闲内存拿去做 page cache，free 很小不代表内存不够，available 才是能分配给新进程的实际余量。df -hT除了看已用百分比，还要顺带看文件系统类型，ext4、xfs、overlay 的处理方式差别很大。

这三条命令的明显局限是只给当下快照，不给趋势。load 是爬升还是下降、内存是稳步泄漏还是瞬时波峰，单看一次输出判断不了，所以还需要下一节的日志和时间线。

2.2 系统日志怎么读：journalctl 与 dmesg 的分工和时间线

日志是故障排查的第一证据来源，但很多新人会把所有日志混在一起看。实际分工很清楚：journalctl管用户态服务和 systemd 单元的日志，dmesg管内核环形缓冲区，两者时间线要能对得上才说明系统时间可信。对不上的时候，先怀疑系统时间漂移，再怀疑日志被策略丢弃，这两个坑我在避坑章里单独讲。

# 看某个服务最近的状态和报错，只看 warning 及以上级别 journalctl -u nginx --since "10 minutes ago" -p warning --no-pager # 看内核消息里的错误和失败记录，-T 把时间戳转成可读格式 dmesg -T | grep -iE "error|warn|fail" | tail -50 # 看今天以内内核级别的错误日志，OOM 和硬件报错一般在这里 journalctl -k -p err --since today --no-pager

-u按服务名过滤，--since限制时间窗口避免日志淹没屏幕，-p按优先级过滤。-p warning表示只看 warning 及以上，这样不会把正常业务日志当成噪音。dmesg -T的-T是 human-readable 时间戳，不加的话输出的是内核启动以来的秒数，对时间线非常不友好。journalctl 的-k只看内核消息，和 dmesg 内容同源，但支持 journald 的过滤语法，适合按时间窗口查。

日志级别从紧急到调试共八级，故障篇里出现频率最高的是err和warning两层。emerg到crit多半伴随系统级问题，notice以下基本可以日常忽略。

dmesg 适合看驱动、磁盘、内存、PCIe 报错，journalctl 适合看应用、systemd 服务、cron 任务。排障时两边各取一段时间对比，如果 dmesg 里有 IO error 而 journalctl 里只有应用超时，那根因八成在存储层而不是应用层。

2.3 五分钟固定证据链：一组可以抄走的排障命令组合

故障处理最怕的不是找不到原因，而是处理到一半发现最早的现场已经被自己覆盖了。所以我强烈建议把这组命令存成脚本或函数，报警时先跑一遍，输出重定向到文件，然后再开始分析。这一步做得好，后面所有定位都建立在同一份现场快照上，事后写报告也有据可查。

TS=$(date +%F-%H%M%S) OUT=/tmp/diag-$TS.log { echo "===== UPTIME ====="; uptime echo "===== MEMORY ====="; free -h echo "===== DISK ====="; df -hT; df -i echo "===== PROC TOP ====="; ps aux --sort=-%cpu | head -15 echo "===== LOAD STAT ====="; vmstat 1 5 echo "===== IO STAT ====="; iostat -x 1 3 2>/dev/null echo "===== SYSLOG ERR ====="; journalctl -p err --since "1 hour ago" --no-pager -n 200 echo "===== DMESG TAIL ====="; dmesg -T | tail -80 } > "$OUT" echo "已保存到 $OUT"

这段脚本把排障最常用的几类信息一次收齐：uptime 对应负载问题，free 对应内存问题，df 对应磁盘空间和 inode，ps 排序找 CPU 大户，vmstat 看 CPU 和 IO 的瞬时状态，iostat 看磁盘压力，journalctl 抓应用和系统错误，dmesg 看内核和硬件现场。文件名带时间戳，方便多次采集后对比。

vmstat 1 5表示每 1 秒采样一次共 5 次，输出里的 r 列是运行队列，b 列是不可中断睡眠进程数，这两列在 CPU 和 IO 故障里是核心判据。iostat -x需要 sysstat 包，如果机器上没装，apt install sysstat或yum install -y sysstat先补上，别等故障时才发现命令不存在。

注意：脚本里加2>/dev/null只是为了避免命令缺失时报错中断，真正分析时每一段都要看，别因为输出多就只 tail 最后几行。

固定完现场，下一步才进入具体故障分支。CPU 和内存问题是最常见的入口，下一章沿着这条路往下拆。

3. CPU与内存故障：从load average 高到OOM 的定位路径与内核参数

CPU 和内存故障在服务器运维里占了大头，但这部分恰恰是误解最多的地方。load average 高不一定是 CPU 跑满了，内存报错也不一定都叫 OOM。先把概念边界划清楚，再谈命令和参数，否则照着网上抄的参数调完，问题反而更隐蔽。

3.1 load average 高不等于 CPU 跑满：先分清 R 和 D 状态

load average 统计的是“可运行进程”和“不可中断睡眠进程”的队列长度。前者是真正在等待 CPU 的 R 状态进程，后者是卡在 IO 等内核操作上的 D 状态进程。两者都会拉高 load，但处理方式完全不同：R 状态多要加 CPU 或减负载，D 状态多要查磁盘和存储链路。

# 每 1 秒采样一次，共 5 次，看 r 和 b 两列 vmstat 1 5 # 列出当前处于 D 状态的进程，优先排查这些 ps -eo state,pid,comm | awk '$1=="D"'

vmstat 输出里 r 列长期大于 CPU 核数，说明 CPU 队列在堆积；b 列不为 0 且有持续增长趋势，说明有进程卡在不可中断的 IO 路径上。故障篇里最常见的误判场景是：load 已经飙到 20，top 按 CPU 排序却看不到明显占用的进程，这时重点查 D 状态进程，用cat /proc/PID/stack或cat /proc/PID/wchan看它卡在哪个内核函数上，往往指到磁盘或 NFS 挂载点。

还需要注意 load 的采样窗口。1 分钟值高但 5 分钟、15 分钟值低，说明是瞬时冲击；三个值一起走高才是持续压力。很多报警系统只盯 1 分钟 load，误报率很高，我一般建议告警规则用 5 分钟值作为触发条件。

3.2 找 CPU 大户：top、pidstat、mpstat 组合拳

确认 CPU 确实是瓶颈之后，下一步是定位到具体进程。top交互界面按 P 键按 CPU 排序是最快的，但 top 的采样模式在故障现场不够稳，最好用pidstat做定长采样，再配合mpstat看多核分布。

# 采样 5 次，每次 1 秒，看进程 CPU 占用 pidstat -u 1 5 # 看每个 CPU 核的使用率，找是否单核打满 mpstat -P ALL 1 3

pidstat -u输出里 %CPU 是进程占所有核的百分比，超过 100 说明这个进程在用多核，比如 8 核机器上单进程 400% 就是占了 4 个核。mpstat -P ALL能看负载是否均衡，多核机器上如果只有 0 号核被打满而其他核空闲，多半是软中断或锁竞争问题，而不是业务负载本身。

容易被忽略的是 top 里的 si（软中断）列。软中断占比高时，top 里看不出哪个业务进程在吃 CPU，但网卡收包、内核协议栈处理都在消耗算力。这时看cat /proc/softirqs的计数增长，配合网卡多队列配置ethtool -l eth0确认 RSS 队列数是否和 CPU 数匹配。这个方向在故障篇里属于“进程层看不到原因、要下沉到内核层”的典型案例。

3.3 不是所有内存不足都叫 OOM：读懂内核日志里的凶手

内存类故障里，OOM 是被误解最深的一个。很多人看到“Out of memory”就认为是物理内存不够，但实际故障篇里有一半的 OOM 案例和 cgroup 限制有关，另一半才是系统级内存耗尽。两者的排查入口完全不同。

# 找内核 OOM 记录，看被杀进程的名字和内存占用 dmesg -T | grep -iE "out of memory|oom-killer|killed process" # 看 systemd 服务级别是否限制了内存 systemctl show nginx -p MemoryCurrent -p MemoryLimit # 查看当前内核的内存策略参数 cat /proc/sys/vm/overcommit_memory cat /proc/sys/vm/swappiness

dmesg 里的 OOM 记录会把触发时的内存拓扑、每个进程的占用、被杀的进程名都打出来，这是系统级 OOM 的第一现场。如果 dmesg 里没有 OOM 记录，但服务反复退出且退出码是 137，那大概率是 systemd 或 cgroup 层面设了MemoryLimit，服务超限被杀。此时查MemoryCurrent和MemoryLimit的对比，而不是去加物理内存。

内核参数方面，/proc/sys/vm/overcommit_memory的三个值含义要清楚：默认 0 是启发式，系统按经验判断是否允许超额分配；1 是总是允许，适合数据库类需要大内存映射的服务；2 是禁止超额，系统按 CommitLimit 严格限制。改成 2 之后如果业务申请内存超过限制，进程会直接分配失败，报错很干脆，但也要把 CommitLimit 一并规划好。

swappiness默认是 60，数值越高内核越倾向于把不常用的内存页换到 swap。SSD 服务器上 swap 抖动对延迟影响很大，常见做法是调低到 10 左右，让内核优先回收 page cache，而不是频繁换页。但这不是万能药：如果程序真的在持续泄漏内存，调低 swappiness 只是推迟 OOM 时间，不解决根因。

3.4 内存泄漏的钝刀子：用 /proc 和采样观察内存趋势

内存泄漏属于故障篇里的慢性病，表面症状是系统用着用着变慢，free 的 available 一天比一天少，重启后立刻恢复，过几天又复发。这种问题最难定位，因为它不报错、不崩溃，只有趋势能说明问题。

# 按常驻内存排序，看进程级占用 ps aux --sort=-rss | head -10 # 每 10 秒刷新一次内存视图，观察变化 watch -n 10 free -h # 看内核态内存 slab 的回收情况 cat /proc/meminfo | grep -E "Slab|SReclaimable|SUnreclaim"

ps aux 按 rss 排序只能看到进程的常驻内存，但进程 RES 包含了共享库的映射，不能简单把多个进程的 RES 相加当成总量。更可靠的指标是 free 里的 available 持续下降，以及/proc/meminfo里 SUnreclaim 字段持续增长。SUnreclaim 是不可回收的内核态内存，如果它一路走高，问题多半在内核态，比如文件系统缓存、驱动或某些内核模块泄漏，这时用slabtop按缓存对象维度继续查。

排查内存泄漏不要只看一时的值，我的做法是连续三天每天同一时间记录/proc/meminfo和进程 RSS 列表，作成简单表格对比。趋势比绝对值可靠得多：available 线性下降就是泄漏，锯齿形波动是正常回收。

4. 磁盘与IO故障：inode 耗尽、iowait 飙升与文件系统只读的处理顺序

磁盘故障在故障篇里的地位很特殊：它不像 CPU 和内存那样有明确的系统级日志，很多问题是“写不进去”“变慢了”“变只读了”这种模糊表象。而且磁盘故障往往和文件系统、内核参数、硬件三层纠缠在一起，处理顺序错了容易二次损坏。

4.1 磁盘没满却写不进文件：inode 耗尽与已删除文件的幽灵占用

“磁盘没满但报 No space left on device”是服务器运维里翻车率极高的一幕。df -h 显示还有几百 G，但业务就是写不进去。这种场景第一反应该是看 inode，而不是怀疑业务代码。

# 查看 inode 使用率 df -i # 找出已删除但仍被进程打开的文件 lsof +L1 | head -20 # 统计目录内小文件数量，定位 inode 大户 find /var/spool /tmp -xdev -type f -mtime +7 | wc -l

df -i的 IUse% 到 100% 就是 inode 耗尽，常见于三类场景：消息队列积压、邮件队列残留、容器日志按天切割产生大量小文件。清理时要先统计再删除，确认目录里是什么业务的数据，别一把rm -rf把正在写入的目录误删。

另一个更隐蔽的情况是有进程已经删除了文件但句柄没释放，文件占用的空间不归还。lsof +L1列出 link count 为 0 的打开文件，找到对应 PID 后重启那个进程，空间才会真正释放。这种情况在日志轮转和临时文件删除场景里很常见，光看 df -h 永远不知道空间被谁占了。

提示：清理 inode 时不要只盯 / 和 /tmp，检查 /var 下的 spool、lib/docker、journal 目录，这些是 inode 消耗大户。

4.2 iowait 高是果不是因：用 iostat 和 pidstat 找到 IO 大户

iowait 指标本身不含任何证据价值。它只是 CPU 等待 IO 完成的时间占比，高说明有进程卡在磁盘，但谁在卡、卡在哪块盘、是读写哪个文件，都要靠 iostat 和 pidstat 追下去。

# 每秒采样一次，扩展模式看每块盘的利用率、等待时间和队列 iostat -x 1 3 # 按进程维度看 IO 读写量 pidstat -d 1 5 # 查看脏页回写阈值 cat /proc/sys/vm/dirty_ratio cat /proc/sys/vm/dirty_background_ratio

iostat -x的关键列是 %util、await、svctm。%util 接近 100% 只能说明磁盘在工作，不能直接断言“磁盘坏了”，因为大量小 IO 也能把 %util 打满而实际吞吐很低。await 是 IO 请求平均等待时间，机械盘和 SSD 的合理范围差异很大，SSD 上 await 超过几十毫秒基本就有问题。svctm 用于估算单次 IO 服务时间，在故障篇里适合做同类磁盘横向对比，不适合跨设备套固定阈值。

定位到某块盘压力大之后，用pidstat -d按进程维度查谁在读写。如果进程维度找不到，还要考虑 page cache 回写导致的 IO：大量写入场景下脏页攒到dirty_ratio阈值会触发集中回写，表现为周期性 IO 打嗝。常见做法是把dirty_background_ratio从默认 10 调低到 5 左右，让回写更平滑地分散。这两个参数在不同内核版本和发行版上默认值不完全一样，改之前先sysctl -a | grep dirty看当前值，再按业务写入量评估。

4.3 文件系统只读：硬件、断电、fsck 三种路径

文件系统突然只读是故障篇里最吓人的场景之一，因为业务会立刻大面积报错。现象很统一：mount 显示 rw，但应用写文件时提示 Read-only file system。但触发原因差异很大，处理顺序错了可能把隐患放大。

第一件事永远是dmesg -T看内核有没有报 IO 错误或文件系统错误。如果是硬件链路问题，内核日志里会有I/O error、nvme或scsi相关的报错；如果是文件系统元数据损坏，会有EXT4-fs error或xfs相关的关键字。看到哪类错误再决定下一步，而不是盲目去 remount。

# 先看内核报错，确认故障层 dmesg -T | grep -iE "ext4|xfs|nvme|scsi|I/O error" # 尝试重新挂载为读写，但只试一次 mount -o remount,rw / # 卸载后做文件系统检查，xfs 先用只读模式检查 umount /data && xfs_repair -n /dev/sdb1

如果 remount 后立刻又变回只读，说明内核在持续检测到文件系统错误，反复 remount 没意义，反而可能加剧元数据损坏。正确做法是停业务、卸载、做文件系统检查。ext4 用e2fsck -f -p，xfs 用xfs_repair -n先只检查不修复，确认问题范围后再去掉-n执行修复。

这里有一个必须强调的红线：不要在生产环境对已挂载的 ext4 直接跑 e2fsck，可能造成二次损坏；xfs 修复必须卸载后进行。在服务器集群里如果这块盘是共享存储，还要先确认其他节点没有同时挂载，否则多节点并发读写会让修复徒劳无功。

4.4 扩容与 fstab：UUID、blkid 与重启后的崩溃现场

磁盘扩容和重启后找不到盘，是故障篇里最浪费生命的一类问题。现象往往是：扩容操作做完，业务正常，但服务器一重启就进 emergency mode，开机脚本全没跑。原因十有八九是 fstab 写的是设备名，设备名在重启后发生了漂移。

# 查看块设备的 UUID 和文件系统类型 blkid /dev/sdb1 # 查看当前 fstab 挂载配置 cat /etc/fstab | grep -v "^#" # 在线扩容 ext4 和 xfs 分别用这两个命令 resize2fs /dev/sdb1 xfs_growfs /mountpoint

fstab 里的挂载项建议一律用 UUID 而不是 /dev/sdX。虚拟机场景下磁盘枚举顺序不固定，插拔磁盘后 sda 可能变成 sdb，按设备名挂载必然出错。blkid拿到 UUID 后在 fstab 里改写成UUID=xxxx格式，非关键数据分区建议加nofail选项，避免单块盘异常导致整个系统起不来。root 分区不要加 nofail。

扩容操作本身也有顺序讲究：云盘扩容后先在系统里让内核重新识别分区大小，再用resize2fs或xfs_growfs扩展文件系统。ext4 支持在线扩容，xfs 的xfs_growfs参数是挂载点而不是分区设备名，这两个命令的入参经常被写反。改完 fstab 后先执行mount -a验证所有挂载项都能正常挂载，再考虑重启，这一步能拦住绝大多数重启翻车现场。

5. 故障排查避坑清单：5个让老手翻车的细节

这一章是血泪经验的集中区。有些坑不是知识盲区，而是顺序和习惯问题。我把故障篇里出现频率最高的五类典型踩坑整理成清单，每条按现象、原因、解决写清楚。

5.1 现象：重启之后查无对证

现象是服务恢复后想复盘，发现 journal 里只有启动后的日志，内核消息全丢了，故障现场变成了黑匣子。很多排障者习惯“重启大法”，但重启前没有做任何取证，重启后系统日志从零开始，等于亲手销毁了证据。

原因是 systemd-journald 在默认配置下把日志写在/run/log/journal，这是 tmpfs，重启即清空。解决办法是在/etc/systemd/journald.conf里把Storage=persistent打开，重启 journald 后日志会持久化到/var/log/journal。此外，每次处理故障前先跑一遍第二章的证据链脚本，让取证成为肌肉记忆。开源的服务器维护软件，比如 Cockpit，也带日志查看面板，能辅助排查，但它展示的还是 journald 的数据源，日志持久化配置不能省。

5.2 现象：日志时间线对不上，证书校验失败

现象是 dmesg 和 journalctl 的时间对不上，差距能达到几分钟甚至小时级；更诡异的是 https 客户端突然报证书有效期错误，但证书肉眼检查明明没问题。原因是服务器没有时间同步，或者虚拟机迁移、挂起后时钟发生漂移。

先timedatectl status确认时区和 NTP 同步状态。国内服务器建议配置国内时间服务器，例如ntp.aliyun.com这类公共 NTP 服务，避免依赖远端时间源。用 chrony 时改/etc/chrony.conf后执行systemctl restart chronyd，然后用chronyc sources验证同步源状态；用 ntpd 的话对应看ntpq -p。时间同步问题不解决，日志时间线永远是乱的，跨服务器排障时根本没法对齐事件顺序。

5.3 现象：journal 里没有报错，日志像被人为清空

现象是系统明明出过故障，但journalctl -p err一条记录都没有，或者在 journal 里看到Failed to write entry, dropping message的提示。原因是 journald 有日志速率限制，单个服务短时间内刷太多日志会被直接丢弃，崩溃前最关键的报错恰好被丢掉。

journald 的RateLimitIntervalSec和RateLimitBurst两个参数控制这条策略，不同发行版默认值差异很大，常见的是 30 秒内允许 1000 条或 5 秒内允许 5000 条。调到足够大，或者按发行版文档建议改成一个更合理的阈值。同时把SystemMaxUse设一个合理的日志总大小上限，避免日志无限增长。改完/etc/systemd/journald.conf要systemctl restart systemd-journald生效。日志是排障的后悔药，这里省下的配置时间，会在下一次故障里成倍还回来。

5.4 现象：连接数爆炸，端口报错，服务却没崩

现象是短连接高并发时应用报Address already in use或连接失败，ss -s里 TIME_WAIT 数量堆积到几万甚至十几万。很多运维的第一反应是怀疑遭遇了攻击，但实际情况通常是连接生命周期太短，TIME_WAIT 状态的 socket 积压导致源端口耗尽。

先用ss -tan看连接状态分布。CLOSE_WAIT 大量堆积说明服务端没有正常关闭连接，这通常是应用层 bug；TIME_WAIT 大量堆积说明连接关闭是正常的，但回收太慢。内核参数net.ipv4.tcp_tw_reuse在客户端场景下可以复用 TIME_WAIT 连接，net.ipv4.tcp_fin_timeout从默认 60 秒调低到 30 秒左右能让 TIME_WAIT 更快周转。这两个参数要按业务形态评估后设置，只调参数不改应用连接池的用法，治标不治本。

5.5 现象：root 也写不进去，文件权限明明是 777

现象是 root 用户创建文件报 Permission denied，但ls -l看权限是 777，所有者也没问题。这类问题最容易让人怀疑人生，因为它绕过了常规权限模型。

排查顺序要固定：先mount | grep 目标路径看挂载选项，是不是被ro或者noexec限制了；再用getfacl看 ACL 访问控制列表，ACL 的优先级高于普通权限位；最后用ls -Z看 SELinux 上下文，SELinux 拦截时报错信息和权限无关，很容易被忽略。测试环境可以临时setenforce 0验证是不是 SELinux 导致的，但生产环境别图省事关闭，正确做法是把上下文改成匹配的类型。还有一种常见情况是 sudo 权限配置错误导致用户无法提权，用sudo -l查看当前用户的授权列表，逐条核对命令和参数限制。

6. 把别人的故障篇变成自己的：用诊断脚本固化排查套路

资料看得再多，不落到自己的工具箱里都是白搭。我从这类故障篇里学到最有用的习惯，不是背住了哪条命令，而是把排障套路固化成一套随时能跑的诊断脚本。这里给你一个可以直接抄进~/.bashrc或/etc/profile.d/srvdiag.sh的版本：

srvdiag() { local ts=$(date +%F-%H%M%S) local out=/tmp/srvdiag-$ts.log { echo "== uptime =="; uptime echo "== mem =="; free -h echo "== disk =="; df -hT | head -20 echo "== io =="; iostat -x 1 3 2>/dev/null || true echo "== errlog =="; journalctl -p err -n 100 --no-pager 2>/dev/null echo "== dmesg =="; dmesg -T | tail -60 2>/dev/null } > "$out" echo "saved: $out" }

这个函数比第二章的完整证据链简短，但覆盖了每次故障必看的六个维度：负载、内存、磁盘、IO、错误日志、内核消息。每次登录服务器或收到报警时先跑一遍，输出存成带时间戳的文件。等定位到根因后，把当时的输出特征和处置方式追加到自己的笔记里，新坑积累多了，那份收集来的 PDF 就变成了你自己的故障篇。

我的习惯是故障处理完不急着庆祝，先花十分钟把这次的现象、误判、关键输出记下来。下一次再遇到同类问题，翻笔记比翻大脑快得多。这套方法和这份故障篇资料一样，核心价值不在命令本身，而在把模糊的恐慌变成确定的流程。希望帮到你。

本文还有配套的精品资源，点击获取