1. 凌晨两点四十七分告警就是命令凌晨两点四十七分手机在床头柜上疯狂震动。我挣扎着摸到手机屏幕上赫然是几条来自监控平台的告警推送生产服务器CPU使用率连续5分钟超过95%load average飙到30。当时第一反应不是“完了又出事了”而是“这次又是什么问题”。这种场景做运维的人多少都经历过。如果你也是个需要和Linux服务器打交道的人——不管是专业的运维工程师、后端开发还是自己折腾服务器的小白——这份经过多次实战打磨的Linux故障排查“作战地图”或许能在你下次被深夜告警炸醒时帮你省下至少半小时的定位时间。很多刚接触Linux排查的朋友最大的困境不是没有工具而是面对终端时不知道该从哪看起。CPU高就杀进程内存不够就加swap磁盘满了就删日志这些“头痛医头”的做法往往解决不了根本问题。一个完整、高效的排查流程应该是一张地图从信号出发按层深入最后锁定根因。这篇文章不会给你一个万能脚本而是给你一套可复用的思维框架和实操命令组合。我会结合这些年踩过的坑讲清楚为什么这样排查、每一步在确认什么、常见误判有哪些。今天要分享的这套排查思路核心可以概括为六个字先止血再定位。系统告警后首先要确保业务不挂、数据不丢然后才谈得上从系统层、日志层、网络层逐层下钻。这套方法论不只适用于已经比较成熟的K8s环境在裸机、虚拟机、嵌入式Linux设备上都同样有效。区别只在于细节而细节恰恰是这篇文章要展开的核心。2. 告警接警后先别急着敲命令——花两分钟做三件事2.1 判断告警等级决定响应策略很多人接到告警的第一个动作就是冲进服务器开始敲top、free、df。这个习惯非常不好。正确的第一步应该是花两分钟时间确认三个信息影响范围、严重程度、持续时间。影响范围指的是什么是单台机器出问题了还是整个集群都在报警如果只是单台多数情况下问题相对可控如果是整个集群可能要优先怀疑基础设施层比如存储、网络、公共组件。严重程度看的是业务受损情况——是响应变慢还是完全不可用持续时间则决定了你有没有时间从容排查还是必须立刻采取激进手段恢复业务。这三件事确认完你才能决定响应策略是直接重启服务先恢复还是可以慢慢定位根因。我在实际工作中遇到过不少同行一上来就埋头看命令输出结果半小时过去才意识到是整个交换机层面的问题白白浪费了黄金恢复时间。这个习惯改过来你的应急响应水平会直接上一个台阶。2.2 确认监控数据的真实性告警数据本身也可能“说谎”。就拿负载偏高这个最常见的告警来说——监控图上load average超过30但当你登录服务器时发现系统响应飞快top里也没有明显的高占用进程。这种情况在重启过某些服务、或者有大批量定时任务启动时非常常见。另一种常见情况是监控平台自身的采集器出了问题。比如曾经遇到过一个案例告警显示某台机器内存使用率99%但上去一看内存占用只有30%多。最后发现是该机器上的监控agent异常采集到了错误的数据。这种时候如果盲信监控就会往完全错误的方向去查。我的建议是不要只盯一个监控指标把CPU、内存、磁盘IO、网络流量、进程数变化这五个维度的趋势图同时拉出来对照看有没有突变点。这个习惯会帮你过滤掉至少三成的无效告警。2.3 锁定时间窗口留存第一现场确认告警真实之后还有一个关键动作记录当前系统状态也就是俗称的“留存现场”。为什么重要因为排查过程中你可能会重启服务、杀掉进程、清理缓存这些操作都会破坏现场后面再想复盘就晚了。我自己常用的命令组合是这样# 记录系统概况和性能数据 uptime date free -h /tmp/pre_check_memory_$(date %Y%m%d_%H%M%S).log top -b -n 1 -o %CPU | head -30 /tmp/pre_check_cpu_$(date %Y%m%d_%H%M%S).log ss -s /tmp/pre_check_net_$(date %Y%m%d_%H%M%S).log这几条命令花不了几秒钟但能留下最原始的状态快照。等故障处理完做复盘时这些数据就是宝贵的对比依据。很多疑难杂症最后都是靠对比故障前后的数据差异才找到答案的。3. 系统层排查从五个维度建立第一张“作战图”3.1 负载与CPU分清“负载高”和“CPU忙”是两回事进入正式排查阶段第一个要看的是系统的整体状态。这里我强烈建议按固定的顺序来形成肌肉记忆避免遗漏维度。第一步看uptime和top理解负载的含义。uptime你会看到类似这样的输出03:15:22 up 128 days, 4:22, 2 users, load average: 28.31, 22.15, 15.08很多人一看到load average高就慌了。但我要强调的是load average高不等于CPU一定忙它统计的是处于可运行状态和不可中断睡眠状态的进程数。这两个状态的进程都会计入负载但处理方式完全不同——前者是CPU排队后者通常是等待磁盘IO、锁或其他资源。判断方法很简单同时看top里的CPU使用率。如果%CPU总和很高比如单核机器上超过100%多核机器上超过核数说明是计算密集如果%CPU不高但load很高大概率是IO等待或锁竞争。这个区分直接决定了你下一步是查进程还是查磁盘。第二步看vmstat快速判断阻塞点。vmstat 1 5重点看三列r运行队列、b阻塞进程数、waIO等待占比。r持续大于CPU核数说明CPU饱和b持续不为0说明进程卡在资源等待上wa高说明磁盘IO大概率是瓶颈。3.2 内存SWAP使用率和缓存回收往往是误判重灾区内存排查同样有章可循free -h在输出中我最关心的是available这一项而不是很多人盯着的used。Linux的内存管理机制决定了它会把空闲内存尽可能用作缓存buff/cache所以used高并不代表内存紧张available才是真正可用的内存估算值。如果available确实很低再看swap的使用情况。swap持续增长、swap in/out频繁说明物理内存已经无法满足需求必须考虑调整应用的内存配置或增加物理内存。这里分享一个经验很多Java应用的OOM问题早期信号就是swap使用率缓慢爬升。如果你在监控里看到这个趋势就应该提前排查JVM堆配置而不是等内存彻底爆掉。还有一个很多人不知道的技巧cat /proc/meminfo | grep -E ^(Dirty|Writeback|AnonPages|Shmem)Dirty和Writeback过高说明有大量脏页等待写回磁盘这种情况下的内存紧张根因反而在磁盘IO性能上。排查思路又会转向IO方向。这就是为什么我一直说排查不能只看单维度指标要学会交叉验证。3.3 磁盘空间与inodedf和df -i要一起看磁盘满是一个很经典的问题但很多新手只查了空间忽略了inode耗尽的情况。df -hT df -idf -hT看的是空间使用率df -i看的是inode使用率。inode耗尽时磁盘可能还有大量剩余空间但系统已经无法创建任何新文件。出现这种情况通常是某个目录下堆积了大量小文件比如临时文件、日志碎片、邮件队列等。定位大目录的方法我推荐用dudu -x -h --max-depth1 / 2/dev/null | sort -hr | head -20-x参数让du不跨文件系统检查--max-depth1控制递归深度sort -hr按人类可读格式排序。这套命令能找到占用空间最大的顶层目录然后逐步下钻。排障中很容易出错的操作是快速清除空间时误删系统文件。稳妥的做法是先定位占用大户通常是日志、临时文件、旧内核确认后再执行删除。一个很实用的小命令是journalctl --vacuum-time7d这条命令只保留最近7天的systemd日志能快速释放几个G的空间。对于维护成本高的老版本Linux还残留旧日志在/var/log下可以用find配合时间戳清理但删除前一定确认文件确实不再需要。3.4 上下文件与进程状态一个容易忽略的隐藏瓶颈另一个容易忽略的维度是文件句柄file descriptor和进程状态。cat /proc/sys/fs/file-nr这个文件输出三列已分配文件句柄数、未使用句柄数、系统最大句柄数。如果第一列逼近第三列说明文件句柄即将耗尽。这种情况在大量建立网络连接或频繁打开文件的应用中很常见会导致应用报“Too many open files”错误。进程状态排查用psps -eo pid,stat,wchan:32,cmd | grep -E ^ *[0-9] D找出处于D状态不可中断睡眠的进程wchan列会显示内核等待的函数。如果很多进程都卡在同一个内核函数上那基本可以锁定是磁盘IO或某个文件系统挂载点的问题。4. 日志层排查journald、应用日志和内核日志的交叉验证4.1 系统日志journald是新一代排障利器系统层指标看完了如果还没找到根因就该进入日志层。Linux系统日志经历了从syslog到journald的演进在主流新版Linux发行版上journald是首选入口。一些最实用的用法# 查看最近的系统错误 journalctl -p err -b --no-pager # 查看指定服务的日志 journalctl -u nginx.service --since 10 minutes ago --no-pager # 跟踪内核消息 dmesg -T --levelerr,warn-p err -b组合非常重要只查看本次启动以来的错误级别日志能过滤掉大量无关信息。-u参数针对具体服务排查时非常趁手。dmesg则适合查看硬件层和内核层的异常比如磁盘IO错误、内存ECC纠错、OOM Killer动作等。一个实战案例有次k8s节点状态异常Pod频繁重启。直接查应用日志没有发现明显报错但用journalctl查看节点的systemd日志时发现kubelet多次因为OOM被系统杀掉。顺藤摸瓜排查发现节点上某个Pod的内存Limit设置不合理拖垮了整个节点的内存预算。如果只查应用日志这个问题可能要折腾很久。4.2 应用日志从时间线对齐中找线索应用日志的排查核心技巧是时间线对齐——把系统层异常的时间点和应用层报错的时间点对齐看能快速圈定因果关系中的嫌疑对象。比如系统日志中显示15:32分发生了OOM Killer动作那么就去应用日志看15:30-15:35这个窗口内有没有异常的报错或请求尖峰两条线一汇合距离根因就不远了。看应用日志不一定非得用tail -f、grep组合。在日志量大的场景我强烈推荐装一下lnav这类工具如果环境允许lnav /var/log/app/application.log它支持多文件时间线同步、正则高亮、SQL查询排查效率比纯grep高出好几倍。当然如果你的环境不方便安装第三方工具grep的基本功也得过硬——grep -iE error|exception|timeout|failed /var/log/app/application.log | tail -200建议在掌握grep的基础上加上--color、-C 5这些参数前者让匹配更醒目后者输出上下文都很有用。4.3 内核日志oom_score和oom_adjOOM Killer的前后手内核日志这块如果你遇到的是OOM问题dmesg里的信息量非常大。除了看到“Out of memory: Kill process”这类关键字还要学会看两个重要指标oom_score和oom_adj。/proc/pid/oom_score是一个动态计算的分数值越高越容易被OOM Killer选中作为牺牲品。oom_adj则是管理员可以主动调整的权重范围从-17到15数值越小越不容易被杀。-17意味着该进程完全被排除在OOM Killer的候选名单之外。合理运用这个机制可以保护关键进程不被误杀echo -17 /proc/$(pidof mysqld)/oom_adj或者用更现代的/proc/pid/oom_score_adj取值-1000到1000。注意这只是临时修改要在重启后依然生效需要写入systemd service或rc.local里。但是要提醒一句调整权重之前先确认这台机器为什么内存不够否则就是治标不治本。5. 网络层排查连接数、丢包与抓包三件套5.1 连接状态统计TIME_WAIT堆积与连接耗尽系统层和日志层查完还没找到问题很多隐藏较深的故障就会浮出水面这时候就该进入网络层。第一步是看整体连接概况ss -s这个命令会输出TCP、UDP、RAW等协议的连接汇总。重点关注TCP的estab已建立连接数和timewait。TIME_WAIT堆积本身不会立刻拖垮系统但如果达到数万级别会占用大量端口和内存间接导致新连接创建失败。定位谁在建立大量连接ss -tnp | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -20这条命令统计各远端IP的连接数。如果发现某个IP的连接数是断崖式领先大概率是有异常流量或外部请求方在做频繁连接。5.2 网卡丢包与RX/TX队列一个隐蔽性能杀手网络性能问题不太容易被top这类工具发现但如果请求出现周期性卡顿就有必要检查一下网卡层面ip -s link show eth0重点看RX errors、RX dropped和TX errors这几项。如果dropped持续增长可能有多种原因环形缓冲区太小、流量超过网卡处理能力、或多队列网卡的队列分配不均匀等。多队列网卡还可以看中断分布是否均匀cat /proc/interrupts | grep eth0如果大部分中断都集中在一个CPU核心上说明网卡中断没有负载均衡这个核心会成为瓶颈。解决办法是开启RPSReceive Packet Steering或调整irqbalance服务这属于进阶调优范畴但排障时知道这个方向能避免在错误的方向上浪费太多时间。抓包工具的使用也值得展开面对HTTP服务响应慢的问题可以先在服务端抓包确认请求到达时间再分析响应延迟。我在定位某次数据库连接池耗尽问题时就是在服务端用tcpdump抓到了大量SYN重传包从而锁定连接数已达上限。抓包基本操作如下tcpdump -i eth0 -nn port 3306 -w /tmp/mysql_debug.pcap抓完用tshark或Wireshark慢慢分析。抓包有两个经验一是先确定“抓什么”不要盲目全量抓二是务必加-w落盘避免直接在终端刷屏导致丢包。6. top、ps、strace三件利器的高阶用法从“看到现象”到“揪出元凶”6.1 top的批处理模式与性能数据快照进到这一层意味着前面几步的通用排查都没能直接命中根因需要把视角从“系统全局”收窄到“具体进程”。这里有一套我打磨过很多次的高阶操作。先说top的批处理模式。很多运维习惯了交互式top但交互式输出不利于留存和分析。批处理模式能稳定输出一次性快照top -b -n 1 -o %CPU | head -40-b表示批处理-n 1表示只执行一次-o %CPU表示按CPU使用率排序。要查进程内每个线程的CPU占用还需要加上-H参数top -b -H -n 1 -p PID | head -50这在排查Java应用、nginx worker等多线程进程时非常关键——比如某Java进程整体占用300% CPU但你可能要找到具体是哪个线程在疯狂运转。找到线程PID后转成16进制用jstack PID | grep -A 20 nid0x...就能看到对应的代码调用栈。这一套组合拳是定位Java应用CPU飙高问题最有效的手段之一。6.2 ps的精确过滤与进程父子关系ps在排查时能帮你快速确认进程状态和父子关系ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd --sort-%cpu | head -30etime列显示进程已运行时间这在判断进程是否发生频繁重启时很有用。如果某个进程的etime只有几分钟而你的监控显示它一直在吃CPU那基本可以认定是不断崩溃重启的死循环。另外一个很实用的是pstreepstree -ap PID查看进程树能帮你快速理清进程之间的父子关系。比如某个守护进程负责拉起多个worker子进程如果worker的父进程不是预期的守护进程就要怀疑有异常程序在大量创建新进程——这种情况无论在哪个领域都很常见每次遇到我都会先停下来确认进程来源再动手清理一旦误杀合法进程接手一个连环故障的场面真的不太好看。6.3 strace与lsof进程级动态跟踪当需要知道一个进程到底在干什么时strace和lsof是压箱底的工具。strace跟踪进程的系统调用strace -p PID -f -e tracenetwork,file,read,write -t-f参数跟踪子线程-e trace限定关注的系统调用类别-t打印时间戳。比如发现某个进程行为异常但ps显示状态正常strace可以立刻暴露它在干什么。lsof则是查看文件句柄的利器lsof -p PID lsof D /var/log # 查看哪些进程占用了日志目录下的文件放一个实际案例来体现strace的价值一次排查中某台机器上有个进程CPU占用并不高但网络连接数持续上涨看状态又不像是正常的业务流量。用strace附加到进程上看到它不断在重复connect某个远端IP的某端口频率高达每秒几十次。再用ss查这个连接的状态基本可以确定是一个失败的同步逻辑在疯狂重试导致连接堆积。定位到具体代码行后修复问题立刻消失。7. 从单次排障到体系化SOP把这套地图变成团队的共同语言7.1 排障过程要有记录复盘时才有依据排查完之后还有一件非常重要但很多人会跳过的事把排障过程记录下来。很多资深运维都认同一个观点排障能力的提升不取决于你处理过多少故障而取决于你复盘过多少故障。我的习惯是这样的故障解决后24小时内趁记忆还热着的时候把以下内容写进wiki或团队共享文档故障现象监控告警截图、用户反馈原文影响范围与持续时间排查时间线每个关键节点、每个命令的关键输出根因分析为什么会出现这个问题恢复手段做了什么操作让系统回到正常预防措施哪些监控能更早发现这个问题这个动作做多了你会发现自己对系统架构的理解会发生质变——因为每一次复盘都在逼你把零散的告警、日志、指标串联成一条完整的故事线。7.2 建立分级排查模板缩短平均恢复时间今年我把这套排查地图做成了团队内部的分级SOP排查层级核心工具判断目标第一层全局状态uptime、top、free、df、vmstat确认是否是CPU/内存/磁盘/网络某一类资源问题第二层日志线索journalctl、dmesg、应用日志找到异常事件和时间点第三层定位进程ps、ss、lsof、strace锁定具体的进程和系统调用行为第四层验证修复指标对比、压测、监控确认确认修复有效且无副作用团队新人拿到这张表即使经验不足也能按图索骥不至于在服务器上像个无头苍蝇乱撞。而经历过一次完整的按模板排查他们对系统的熟悉程度会有明显跃升。7.3 监控规则的持续优化还有一个更本质的问题值得思考这个故障能不能靠监控提前发现很多告警之所以出现在深夜恰恰是因为监控粒度、阈值设置不够合理——要么是根本不知道什么指标该盯要么是阈值设得太宽松等到烧穿时才被察觉。每次排障结束我都会问自己三个问题这个问题发生时哪个指标首先出现了异常现有的监控是否覆盖了这个指标告警阈值是否在“可预警”和“可容忍”之间取得了平衡持续迭代这套监控规则尽可能把告警消灭在研发阶段。这里再分享一个我反复用到的思路除了资源类指标CPU、内存、磁盘尽量给业务指标也加上监控。比如接口响应时间、成功请求数、队列堆积量——这些指标往往比底层资源告警更早反映出问题。资源指标是“身体指标”业务指标是“主观感受”两者结合才能更早嗅到风险的气息。尤其是做K8s排障的时候这个思路能够更好地区分“某个Pod出了问题”和“整个集群资源不够了”一线的排查效率会差很多。8. 最后一次踩坑的教训深夜告警未必来自你以为的那台机器在文章最后我想用最近一次真实踩坑经历来收尾。某天凌晨监控大量告警显示某个核心服务响应超时。按部就班登录服务器CPU不高、内存充足、磁盘IO正常、日志也没有明显报错。整整一个小时我都在这台机器上绕圈几乎要怀疑是应用层代码的偶发问题。后来抱着试试看的心态排查了这台机器所在的宿主机状态——发现问题根本不在当前登录的这台虚拟机上而是宿主机因为某个失控的磁盘IO任务导致整体性能被拖垮。在裸机和虚拟机环境里这其实是个非常经典的问题虚拟机里看到的CPU和内存是虚拟化分配的但磁盘IO和网络IO是共享宿主机物理资源的。宿主机一出问题上面所有虚拟机都会受影响。这个案例给我三个很深的教训第一出现批量告警时先在集群和基础设施层面排除共性故障再深入单点查细节第二虚拟化环境的排查必须保留宿主机的监控视角第三越急越容易绕圈子冷静按地图走比凭感觉冲更快。如果你也常被Linux服务器故障熬得焦头烂额不妨把这套方法整理成适合自己的速查清单。等下一次深夜告警亮起的时候你可能比以前的自己镇定了不止一点。
