深夜收到一连串告警屏幕上红色的Error刷屏这种体验干运维的都懂。手边要是没有一套成熟的排查思路大概率是救火队长模式哪里报错修哪里一晚上过去问题没根治还把自己熬到虚脱。这篇文章把我这些年处理Linux故障的完整打法整理成一份“作战地图”从接到告警的第一反应到在线排查工具链的组合使用再到常见故障场景的标准处理流程最后聊聊告警治理和值班经验希望能帮你在下一次深夜告警时稳住阵脚。先说清楚这份地图适合谁看。刚入行的运维新人可以用它建立排查框架遇到告警不至于手忙脚乱干了几年但主要靠经验救火的同学可以对照检查自己的排查流程有没有遗漏即使是后端开发或者SRE这套思路对线上问题的定位处理一样有参考价值。1. 告警炸裂时的第一反应先稳住再分级告警一多人最容易犯的错误就是被告警牵着走。我见过不少同事一晚上处理了十几个告警最后发现根源只有一个其他都是连锁反应。所以我处理告警的第一原则是先花两分钟看全貌再动手碰任何一台机器。1.1 把告警分成三个优先级接到告警轰炸时我习惯先按影响范围和服务层级给告警分个类就像急诊分诊一样。第一优先级是直接面向用户的告警比如核心API集群不可用、数据库主从切换失败、消息队列积压持续上涨。这类告警影响的是用户可感知的业务必须立刻响应哪怕还没定位到根因也要先做止血操作比如重启异常节点、切流到备用集群。第二优先级是资源类和依赖类的告警比如某台机器CPU飙到95%、磁盘使用率超过阈值、下游服务超时率上升。这类告警往往是根因所在需要按资源类型逐项排查但不能盲目重启否则可能掩盖真正的问题。第三优先级是边缘告警和噪音告警比如非核心业务的慢查询、某台机器负载短暂冲高又回落、证书还有一周过期这种预警类通知。这类内容可以放到告警群里记录但不要中断主线排查节奏否则一晚上就耗在里面了。1.2 建立“告警全景图”再动手具体做法是把接收到的告警按主机名、服务名、告警类型三个维度列成一张表先找出哪些告警的宿主是同一台机器哪些告警是同一时间点集中爆发的。如果一台机器同时报了CPU高和响应慢而另一台机器只是磁盘告警那大概率CPU高的那台才是主角。举个例子有一次凌晨两点收到三拨告警线上支付服务P99延迟飙升、支付网关所在机器的CPU超过90%、同一台机器的内存使用率也偏高。表面看是三个问题但其实它们的源头都是这台机器上有个Java进程在做Full GCCPU和内存告警全是它引起的。如果上来就重启服务问题可能会暂时缓解但下次高峰流量一来又会复发。先看清楚关联性才能避免被表象带偏。实操中我建议把前十分钟定义为“观察期”只做三件事看告警列表、看核心业务的错误率曲线、看集群的整体负载趋势。十分钟后再决定是进入止血流程还是进入定位流程。这个节奏能有效避免手忙脚乱。2. 在线排查工具链你的随身“瑞士军刀”Linux排查故障离不开命令行工具。但很多人只是记住了命令的参数不知道什么场景该用什么命令组合。这里把我常用的工具链按资源维度拆开每类都给出推荐的组合用法和判断依据。2.1 CPU类问题的工具组合CPU告警是最常见的夜间告警处理思路是先看整体负载uptime再定位到进程top最后细化到线程和代码片段pidstat、jstack逐层逼近。# 先看系统平均负载判断是否还有余量 uptime # 按CPU占用排序锁定可疑进程 top -o %CPU -n 1 # 查看指定进程内的线程CPU占用 pidstat -t -p PID 1 5 # 导出线程栈分析线程在做什么 jstack PID jstack_$(date %s).log判断标准是这样如果load average长期高于CPU核数说明系统已经被压满如果只是瞬时飙高可能是定时任务或突发流量。拿到线程栈后重点搜“RUNNABLE”状态的线程和GC相关日志“GC task thread”等基本能快速定位是业务逻辑死循环还是JVM频繁GC导致。这里有个实操经验top命令默认刷新间隔是3秒排查高并发问题时建议把刷新间隔调到1秒否则峰值会一闪而过。另外多核机器上建议按“1”键看每个CPU核心的利用率分布如果只有单核跑满大概率是单线程瓶颈或者锁竞争和整体CPU资源不足是两回事。2.2 内存类问题的工具组合内存告警的难点在于区分“真的不够用”和“内存泄漏”。我用free命令时有个习惯重点看available列而不是free列因为Linux会把空闲内存用作缓存free数值低不代表内存紧张available才是真正可分配给新进程的内存量。# 查看内存整体情况 free -h # 查看进程级内存占用 ps aux --sort-rss | head -20 # 动态追踪进程内存变化判断是否持续增长 pidstat -r -p PID 1 30 # 查看系统页表、slab等内核内存占用 cat /proc/meminfo | grep -E Slab|SReclaimable|SUnreclaim排查内存泄漏时pmap和gdb可以配合使用。先用pmap查看进程的地址空间分布如果某个anon映射段的内存持续增大就说明有内存没被释放。Java服务则可以用jmap导出堆转储文件再用MAT分析对象引用链找到占用内存的根源。线下压测阶段能发现的内存泄漏尽量不要拖到线上告警再查。2.3 磁盘与IO类问题的工具组合磁盘告警有两类一类是空间满了一类是IO读写性能下降。两类问题的处理方式完全不同先说空间类。# 查看各分区使用率 df -h # 查找大文件注意排除挂载点干扰 du -sh /* 2/dev/null | sort -rh | head -10 # 查看被删除但仍被进程占用的文件这类文件不释放直到进程退出 lsof | grep deleted第三条命令是很多新手会忽略的“坑”。线上经常出现这种情况du统计时磁盘没占多少空间可df显示磁盘已经100%。这说明有进程打开了已被删除的文件文件句柄还挂着空间“幽灵式”占据。处理方式是重启持有句柄的进程或者用echo /proc/PID/fd/FD编号来清空文件内容。IO性能问题则要看iostat的await和util指标。如果util接近100%但await不高说明设备已经接近饱和如果await很高但util不高可能存在锁竞争或底层存储链路异常。排查时可以用iotop按进程维度的IO占用排序快速定位是哪个进程在疯狂读写磁盘。2.4 网络类问题的工具组合网络告警在深夜出现的频率极高而且伪装性强。有时是应用上报的“连接超时”但实际是DNS解析变慢有时是用户反馈“页面打不开”但实际是机房出口带宽被打满。排查网络问题时我习惯从链路层往上逐层确认。# 查看所有TCP连接状态统计 ss -s # 查看指定端口的连接数 ss -tan | grep :8080 | awk {print $1} | sort | uniq -c | sort -rn # 查看网络流量确认带宽是否打满 iftop -n -P # 抓包定位丢包重传情况 tcpdump -i eth0 tcp port 8080 -w night.pcapTCP连接数的状态分布很有讲究。如果TIME_WAIT大量堆积说明有大量短连接被频繁建立关闭可以考虑开启tcp_tw_reuse或者改成长连接池如果SYN_RECV堆积说明服务端接受连接的队列满了可能需要调整net.core.somaxconn和应用的backlog参数如果大量连接处于ESTABLISHED但业务没响应就要结合应用日志看线程池是否耗尽。3. 典型故障场景实战从告警到根因的四步法工具介绍得再多不如直接看几个完整案例的排查链路。我把日常最常遇到的四类故障整理成标准处理流程每一步都有明确的命令和判断依据遇到同类问题可以直接按图索骥。3.1 高CPU告警从进程到线程再到代码某次线上告警订单服务的四台机器CPU全部飙到99%服务超时率明显上升。我按四步法排查。第一步uptime确认负载情况。结果是load average达到了32而机器是16核的说明负载已经是核数的两倍系统严重超载。第二步top -o %CPU -n 1定位CPU消耗最高的进程。发现有一个Java进程PID24567的CPU占用高达340%明显不正常。正常服务在高并发下CPU核内占用顶多到100%多点超过300%说明有线程在疯狂空转。第三步用pidstat -t -p 24567 1 5找出具体消耗CPU的线程号观察到线程TID45231持续占用接近100%。把线程号换算成十六进制0xB0AF然后用jstack导出线程栈搜到这个十六进制值代码定位在订单超时回调模块的一个while循环里。第四步结合业务日志确认该while循环在没有收到上游响应时会无限轮询重试且重试间隔为0。当上游接口在峰值时段响应变慢时这个bug就被放大了形成了CPU空转风暴。修复方式是给重试加指数退避和最大次数限制。这套流程从接到告警到定位代码大约花了25分钟。其中jstack的分析是最耗时的一步线上如果时间紧急可以先通过重启来缓解但务必要保留现场把线程栈导出留档作为后续分析依据。3.2 内存持续增长用数据曲线确认泄漏而不是猜测内存类告警最忌讳的是“重启大法”因为重启后内存会暂时下降但根本问题没解决过几天还会继续告警。我的经验是用数据说话连续采集曲线来确认是否真的属于内存泄漏。场景是这样的某个日志采集Agent节点报内存超过85%并且出现OOM杀进程的迹象。我先用free -h看了整体内存发现used在持续上升available从2.1G一路降到400M而整个节点上并没有新增业务进程。然后用pidstat -r -p PID 1 60连续采集一小时画出RSS变化曲线观察到这进程的RSS呈单调上升趋势从800M涨到了1.9G没有回落迹象。这种情况基本可以判定内存泄漏而不是业务高峰期的临时内存波动。接下来用pmap -x PID分析内存映射发现一个叫“local_cache”的匿名映射段从200M涨到了1.1G。再查看该进程的日志发现有个缓存清理逻辑对“已经关闭的日志文件流”做了缓存但关闭后没有从缓存中移除引用。修复后再次观察曲线RSS稳定在1.1G左右不再增长才算真正收敛。3.3 磁盘写满抓出“日志大户”和隐藏的孤儿文件磁盘写满的告警往往伴随着服务无法写入临时文件、监控数据上报中断等问题影响范围不小。我处理过一次日志盘100%的告警排查过程可以做个参考。df -h显示/data分区使用率100%但du -sh /data/*统计出来只有60%左右差了将近40G。这个差值一眼就让我想到了“被删除但仍被占用的文件”这个经典场景。用lsof | grep deleted查到了两个进程分别持有着已经被删除的日志文件和临时数据文件总计约35G。持有者是日志轮转组件和消息队列的存储模块。原因是日志轮转组件在切割文件时没有通知持有者重新打开文件句柄。处理方案是对这两个进程进行平滑重启让它们释放旧句柄、重新打开新路径下的文件。重启后df的使用率立刻降到了70%。另外排查空间问题时find /data -type f -size 500M -exec ls -lh {} \;也是个好帮手可以快速找出超大文件通常这些文件是dump日志、上传的临时包或者是没配清理策略的备份文件。3.4 网络超时先用链路分层法缩小范围网络超时告警最容易让人误判为“机房网络故障”。实际处理中真实带宽故障占比反而不高更多的还是连接数耗尽、DNS解析慢、防火墙限制或应用自身处理不过来。我用的排查方法是链路分层法客户端到服务器的网络连通性、TCP连接建立、HTTP请求处理耗时逐层确认延迟发生在哪一段。先ping目标IP看基础连通性如果ping延迟超过20ms同时伴随丢包先怀疑物理链路或负载均衡设备。连通正常后再用curl -w输出各阶段耗时重点看dns解析耗时、tcp_connect耗时和total_time。如果total_time高但connect正常说明问题出在应用处理层转而查应用日志、线程池活跃线程数、GC频率。如果connect时间高则可能是连接队列满了检查ss -tan里SYN_RECV和ESTABLISHED的数量适当调大应用监听队列。有一个容易忽略的“坑”是很多服务接入负载均衡后ping测试的是VIP的连通性而后端真实节点可能已经网络异常了但VIP仍然可达。所以不要只测VIP要直接测后端节点IP的连通性或者用telnet 后端IP 端口确认四层是否通。4. 告警治理减少轰炸把力量留给真故障有年头的业务系统告警噪音率普遍很高动不动就告警反而让值班的人麻木。深夜告警“炸裂”的另一个侧面往往就是告警规则设置不合理、通知渠道没打通、屏蔽策略不管用这些“后脖子”问题。这部分我单独拿出来聊聊。4.1 告警分级与聚合规则怎么配告警配置最初级的目标是“出问题能收到通知”但成熟的目标是“出问题能收到正确粒度的通知”。我的建议是设立四级告警体系紧急P0对应核心业务不可用直接电话加短信高P1对应非核心业务受损或核心资源达临界值发钉钉/企微群艾特中P2对应资源使用率趋势性偏高发群里记录低P3为周报级别只出现在日常巡检报告里。聚合规则也很关键。同一台主机上的“CPU高”“内存高”“磁盘IO高”这三个告警本质上是同一个应用的同一场故障需要聚合成一条“P0-P1-主机故障”的总结消息而不是三条独立告警轰炸。主流的监控平台如Prometheus Alertmanager、Zabbix都支持按主机和服务做告警分组务必把分组的key设计成“实例服务”的组合。4.2 常见告警屏蔽失效的处理思路关于告警屏蔽不生效我遇到过几种典型场景逐一说明。一种是与时间窗口有关。有些监控平台在屏蔽时要求指定“开始时间和结束时间”如果屏蔽时间设置成“00:00到09:00”而告警发生在凌晨00:30平台判断为生效范围但如果你设置的是“00:00到09:00”且告警历史发生在00:29那就是差一分钟也要先看屏蔽窗口边界是否真正覆盖了告警时间。另一种是屏蔽对象与告警对象不完全匹配。比如屏蔽规则只选中了“主机A”但告警实际由“主机A上的某个服务”触发如果平台的屏蔽维度是“服务”就需要补充服务维度的屏蔽规则。还有一种更隐蔽的情况动态阈值类的告警比如基于基线偏差的检测在数据源发生变化时会重新计算基线屏蔽期间告警虽然不推送但算法内部仍可能在训练模型解除屏蔽后因为基线被污染很快又会产生新一轮告警。这种情况需要在平台侧找到“学习模式”开关屏蔽期间保持基线冻结或者手动重置基线。4.3 告警通知渠道的落地配置告警通知渠道五花八门但核心要求是一致的快、准、稳。快是指延迟低略有突发就要秒级触达准是指关键信息齐全不依赖值班人再登录平台去查稳是指渠道本身的高可用不能告警渠道比业务还先挂。这里想多说一句Webhook的配置。很多人在配置告警推送给钉钉/企微群机器人时只验证了“能收到消息”这一层没验证消息内容模板的兼容性。如果消息模板里包含了特殊字符或超长字段Webhook推送可能会被服务商截断或拒绝。配置完成后一定要主动触发一条测试告警确认消息里主机名、IP、告警等级、当前值、阈值、跳转链接这些关键信息都完整。至于Zabbix 7.0推钉钉Webhook告警的具体配置需要在“媒介类型”里新建“Webhook”类型的媒介URL填钉钉机器人生成的Webhook地址请求方法选POSTHeader里设置Content-Type为application/jsonBody模板里把{ALERT.MESSAGE}和{ALERT.SUBJECT}嵌入到JSON结构中。配置完之后在用户设置里给接收人关联这个媒介并在“动作”里绑定对应的条件这样才能真正触发。4.4 告警手动确认与关闭操作告警进来了之后值班的人需要手动确认并关闭这是告警闭环的重要一环。很多平台支持在告警详情里做“确认Acknowledge”和“关闭Close”但这两者的语义不同确认代表“已知晓正在处理”关闭代表“已解决不再展示”。我在值班规范里明确规定所有P0和P1告警要求在收到后5分钟内点击确认避免其他同事重复介入只有确认根因并修复、且连续观察一个完整的检测周期后才允许关闭告警。一些场景下比如机房割接、版本发布期间可以采用“定期屏蔽”的方式给屏蔽设置明确截止时间并安排到期后的复核这样既不影响正常告警接收也能规避发布期间的误报轰炸。5. 深夜值班的三条保命建议工具和方法都聊通了最后分享几条我在深夜值班中总结出的“保命”经验谈不上全面但都是亲身踩出来的。5.1 现场保留优先于快速恢复第一反应通常是“赶紧重启恢复”但如果是在生产环境我希望你多问一句这个重启会不会丢现场现场包括当前的进程状态、网络连接状态、系统日志尾部、Java线程栈、核心dump文件这些是事后分析根因的重要素材。我的操作顺序是先执行完整的状态采集命令把输出存到本地和远程OSS/对象存储然后再决定是否重启。采集命令按固定脚本批量执行包括top、free、ss、dmesg、jstack针对Java进程、sar抽样。一次采集大约30秒换取的是后续分析的确定性这笔账怎么算都划算。5.2 把“应急预案”变成可执行脚本很多时候深夜处理故障之所以慌是因为临时要度娘找命令。我的建议是提前把高频故障的应急脚本写好放到服务器固定目录下比如/ops/bin/需要时一键执行。脚本分两类采集类和止血类。采集类脚本负责收集CPU、内存、磁盘、网络、进程、日志等现场信息打包成zip输出到指定目录。止血类脚本则包含一些常规的应急操作但这类脚本要严格经过测试不能在生产环境第一次执行。运维工作里最值钱的就是“确定性的处理流程”。告警到来时手忙脚乱不是因为知识不够而是因为决策链路过长。提前把“什么情况做什么操作”固化下来本质上就是在降低深夜决策的认知负担。5.3 复盘比救火本身更重要处理完告警并不代表这次故障就画上句号。真正让运维团队升级的是事后的复盘和改进。我坚持用的复盘模板有五个关键词时间线、影响面、根因、改进项、验证人。时间线记录从告警触发到恢复的每个关键节点看哪一步耗时最长影响面除了“多少台机器、多少用户”外还要评估“流失了多少监控数据、对容量规划有什么影响”根因分析要求区分“直接原因”和“间接原因”直接原因往往是某个bug间接原因则可能是没有压测、没有容量评估、没有日志埋点改进项要具体到“谁、什么时候、完成什么”不落地的复盘就是走形式最后由指定的人员在预定时间验证改进效果形成闭环。复盘的目的从来不是追责而是让下一次告警来临时你的“作战地图”能更新一个版本比以前更完善。Linux故障排查这门手艺说到底拼的不是记忆力而是遇到问题时的思路清晰度。工具命令可以随时查但如果大脑里没有一条稳定的排查链路查到了也不知道该用在哪里。希望这份“作战地图”能帮你把散落的排查点串联成线下次深夜收到告警时心里有底手上有序。