予晚凌晨三点被告警电话叫醒，切到跳板机，发现线上服务器 CPU Load 已经飙到 20 以上，业务接口超时率直线上升。这个场景，干运维的朋友应该都懂。起初我也是一看告警就慌，登录服务器就是 top 敲完再敲 free，来回折腾半小时才找到方向。干得久了，我意识到真正缺的不是某条命令，而是一套能覆盖“告警触发→信息收集→问题定位→恢复验证”的排障思路。这份 Linux 故障排查“作战地图”，就是把深夜踩过的坑、试过有效的方法整理成一套可复用的流程，适合刚接手服务器、经常被告警折磨的一线运维，也适合需要自己维护测试环境的开发和系统管理员。看完你至少能明白：告警响了，第一件事做什么、用哪些命令拿信息、怎么一步步把问题钉死。
1. 告警响了别慌：先建立一套自己的排障反应流程
1.1 深夜告警的第一原则：先恢复，后定位
很多人告警一响就急着找根因，我的建议恰恰相反：先把业务恢复到一个可用状态，再慢慢排查原因。因为你凌晨三点面对的是用户投诉和故障时长压力，不是学术研究。比如 MySQL 连接数被打满，先重启连接池、杀掉异常会话，甚至把只读流量切到从库，都比盯着监控图发呆有效。这个顺序不是不重视根因，而是把损失降到最低之后，你才有充足的时间去翻日志、查趋势。
另一种容易被忽视的情况是告警已经严重到主机无法登录，比如内存耗尽导致 SSH 都连不上。这时候任何远程命令都是奢望，只能走带外管理（比如服务器厂商的 BMC/IPMI 管理口）重启，或者请机房同事协助断电重启。所以我会在每台服务器上提前配上带外管理地址，并记在资产表里，而不是等到故障现场再来翻文档。
“先恢复”有个前提：你要能判断这个告警是单点问题还是大面积故障。如果只是一台机器挂掉，直接把流量摘掉恢复服务；如果是整个集群都异常，那就不能盲目重启，否则可能引发雪崩。我的习惯是先在脑子里过一遍：这个告警影响哪些业务？有没有依赖关系？有没有正在执行变更？这三件事确认完，再动手。
1.2 告警分级与信息收集清单
告警不是全都需要连夜处理的。我自己会把告警粗略分成三层：
- P0 业务不可用：比如 HTTP 500 比例飙升、核心接口成功率骤降、机房网络抖动，这类必须立即响应。
- P1 容量水位告警：磁盘使用率超过 85%、CPU 持续跑满、内存不足，这类可能恶化成 P0，需要马上看趋势。
- P2 杂项告警：比如某个非核心进程重启、备份任务失败，这类可以白天处理，但要在告警群里留痕。
判断层级之后，立刻收集现场信息。我通常打开一个临时文件，把下面几项记录下来：告警触发时间、监控指标和阈值、影响的主机 IP、最近有没有发版或配置变更、告警持续时间。这里最容易遗漏的是“变更”信息，很多故障追根溯源最后都发现是当天下午某个配置改动在晚上才暴露。你可以顺手看下最近的操作审计记录和登录记录，往往能少走弯路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 手把手拆解 Linux 故障排查的核心路径
2.1 登录主机后第一分钟要做什么
我给自己定过一个规矩：登录故障主机后，前 60 秒只看五类信息，不看业务日志，不翻配置文件。这个习惯让我避免了很多次“查了半天发现方向错了”的尴尬。
第一看时间。date 确认主机时间和监控时间有没有偏差，如果偏差超过五分钟，你后面看到的监控曲线和日志时间轴可能对不上。第二看负载。uptime 会告诉你 1/5/15 分钟的平均负载，如果 1 分钟明显高于 15 分钟，说明负载是刚刚起来的；反过来则说明问题已经持续一段时间。第三看系统整体状态。top 按 CPU 排序，看看是谁在消耗资源。第四看磁盘空间。df -h 和 df -i 检查空间与 inode，这是告警里最常见的一类。第五看内存。free -h 扫一眼总量、已用、缓存和可用量。
这五步做完，你心里应该有一个初步结论：是 CPU 问题、磁盘问题、内存问题，还是更像是业务层问题。接下来再去针对性深挖，效率会高很多。
2.2 系统性能排查的常用命令组合与解读
top 命令输出里的 load average 经常被人误解。它不代表 CPU 使用率，而是代表处于可运行状态和不可中断睡眠状态的进程平均数。判断瓶颈时，我会把负载和 CPU 使用率结合起来看：负载很高但 CPU 使用率也很高，说明进程在拼命算，是真的吃 CPU；负载很高但 CPU 使用率很低，那大概率是有进程卡在 IO 等待上，比如磁盘性能不行或锁竞争，此时要去看 iostat。
我常用的组合是：top 看全局，vmstat 1 5 看 CPU、内存、IO 的快速快照，iostat -x 1 看每块磁盘的利用率、等待队列和平均等待时间，sar -q 看历史负载趋势。这一套下来，瓶颈在 CPU 还是 IO 基本就清楚了。需要注意的是，云服务器上的 iostat 看到的可能是宿主机虚拟磁盘的指标，不一定能反映真正的物理磁盘，所以还要结合监控平台里的磁盘延迟指标一起判断。
内存方面，free -h 里的 available 才是真正的可用内存参考值，而不是 free 列。Linux 会把空闲内存用作 Page Cache，用于缓存文件数据，这部分内存在需要时会自动释放给应用程序，所以在 Linux 上看到“已用内存 90%+”，不一定代表内存不足，要结合 cache 大小和 available 来综合判断。
2.3 查日志的正确姿势：不慌才能查准
日志是排障的“记事本”，但很多新手是打开日志文件从头看到尾，找不到关键词就干瞪眼。我的顺序是先看系统日志，再看应用日志，最后看业务日志。系统日志在 /var/log/messages、/var/log/syslog 以及 journalctl 里，重点关注 OOM（Out of Memory）、内核 panic、磁盘 IO 错误、网络链路 down 这类明显事件。
比如查最近一次内核报错，可以用 journalctl -k -p err -b 查看本次开机以来的内核错误；如果要看上次开机时的报错（比如服务器重启过），就把 -b 换成 -b -1。应用日志位置视中间件而定，Nginx 默认在 /var/log/nginx/，Java 应用看你自己配置的日志路径。日志查看工具上，我会优先用 journalctl，因为它有时间范围查询，比如 journalctl --since "2024-12-10 00:00:00" --until "2024-12-10 00:30:00"。
翻日志时还要注意时区问题。默认系统日志按服务器本地时间记录，监控平台可能用的是 UTC 或东八区，如果两边对不上，你极有可能找错时间窗口。另外，应用日志里如果出现大量异常堆栈，不要只盯着第一条，要看堆栈里的根因部分（通常是 Caused by），那才是问题的真正源头。
3. 五大高频告警场景实战复盘
3.1 CPU 负载走高：真的全是 CPU 的问题吗
CPU 告警是我遇到最多的一类，但排查方向往往不是 CPU 本身。最常见的情况是：某个 Java 应用在做频繁 Full GC，或者业务的线程池被打满，导致 CPU 上下文切换暴增。此时 top 里能看到某个进程 CPU 占用接近核数上限，数据上表现得像“CPU 不够用”，实际上可能是代码死循环、锁竞争或 GC 配置不合理。
我的排查动作是：先用 top -Hp PID 找到进程内 CPU 占用最高的线程号，注意这个线程号是十进制，而 Java 线程栈里的 nid 是十六进制。用 printf "%x\n" 线程号 转成十六进制后，再通过 jstack PID | grep -A 30 "nid=0x..." 找到对应线程栈，看看这个线程在干什么。如果栈顶是 GC task，那就是垃圾回收问题；如果是业务方法的调用栈，就要去查代码逻辑了。
还有一个容易忽略的地方：容器环境下，top 里显示的 CPU 使用率可能是整个宿主机的视图，你在容器里看到的 CPU 占用和宿主机监控里看到的并不一致，需要结合 cgroup 的 CPU 限制来判断。如果容器 CPU Limit 设得太小，业务一上来就会触发 CPU throttling，呈现出来的现象同样是接口变慢，但问题根源在资源配额。
3.2 磁盘告警：空间满了，也可能是 inode 满了
磁盘告警最直接的处理方式是清理大文件，但清理前一定要先确认是磁盘空间还是 inode 不足。df -h 显示空间还剩 20%，但 df -i 显示 inode 已经 100%，说明文件数量太多而每个文件都很小，典型场景是邮件队列、日志碎片、临时文件没清理，或者某个程序在疯狂写零字节文件。
定位大文件时我会用 du -sh /* 2>/dev/null | sort -rh | head -20 从上往下找目录，再逐层 du 进去。找几天内变大的文件可以用 find /data -type f -mtime -1 -size +500M -exec ls -lh {} \;。如果是 inode 问题，就用 find /data -xdev -type f | wc -l 统计文件数，再用 for i in /data/*; do echo "$i $(find $i -type f | wc -l)"; done 这种方式定位哪个目录文件特别多。
清理文件也有讲究。直接用 rm 删除大文件前，先确认是否有进程仍然持有该文件的句柄，否则删完之后磁盘空间不会立刻释放，这种情况可以 lsof | grep deleted 找到对应进程，重启进程或让进程重新加载日志文件。生产环境里每次清理前我习惯先看文件是不是业务还在写，如果是日志文件，要先通知业务方，避免把有保留价值的日志清掉了。
系统日志的轮转也值得提前配置好。Linux 自带的 logrotate 可以按大小或时间切割日志并清理旧文件，我第一次处理 Nginx 访问日志导致磁盘告警时就是靠它解决的。配置文件放在 /etc/logrotate.d/ 下面，比如：
bash复制/var/log/nginx/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0640 nginx adm
}
3.3 内存告警：free 命令背后还藏着什么
内存类告警最常见的表象是“可用内存不足”或“OOM 导致进程被杀”。先说如何判断：用 free -h 看 available 列，如果是几百 MB 甚至接近零，说明系统内存压力很大。再用 top 按内存排序（按 M 键），找出 RSS 占用最高的进程。RSS 高不代表它就是罪魁祸首，有些进程（比如 JVM）会把堆内存预申请到固定大小，实际用到的不多；有些则可能是内存泄漏，持续几天涨上去再也降不下来。
要识别内存泄漏，不能只看当前快照，最好连续看一段时间。我常用下面这个循环，把内存占用最高的几个进程每 30 秒打印一次：
bash复制for i in {1..20}; do date; ps aux --sort=-%mem | head -11; sleep 30; done
如果某个进程的 RES 值一直上涨，重启后短暂恢复、再持续上涨，那就高度怀疑泄漏。Java 应用可以用 jstat -gcutil PID 1000 看 GC 后的堆占用是否持续走高，再用 jmap -heap PID 看堆参数。核心应用做 dump 要谨慎，jmap 执行期间会暂停业务线程，最好在低峰期做。
关于 OOM，内核会通过 oom_killer 选择进程杀掉并记录日志。查 dmesg -T | grep -i oom 或 /var/log/messages，能看到类似 Out of memory: Kill process 的记录。这个信息很关键，它能告诉你是哪个进程触发 OOM，以及当时系统总内存和进程内存的分配情况。我的习惯是给重要的数据库进程设置一定的 OOM 保护：写 systemd service 或调 /etc/security/limits.conf，让核心进程不容易被误杀。但这不是让你关掉 OOM Killer，它只是系统最后的兜底手段。
3.4 网络类故障：连接数、延迟与丢包的排查思路
网络告警的上报维度很多，常见的有带宽打满、连接数超限、TCP 重传率升高、端口不通。处理的第一步，是先区分问题在哪一层。ping 能通说明三层基本通，telnet IP 端口 不通可能说明端口监听有问题，或者防火墙/安全组拦截了。
端口不通时，先确认服务进程还在不在：ss -lntp | grep 端口号。如果进程在但外部连不上，要看本机防火墙和云安全组规则。我遇到过不少次云服务器上明明服务正常，但安全组没放行新端口，排查了半天才发现是云控制台里没配规则。
连接数超限时，我会用下面的命令看当前的 TCP 连接状态分布：
bash复制ss -ant | awk '{print $1}' | sort | uniq -c
SYN_RECV 大量堆积，可能是有攻击，也可能是后端处理不过来；TIME_WAIT 多一般是短连接场景的正常现象，但如果量大到占用端口资源，可以调整内核的 net.ipv4.tcp_tw_reuse 和 net.ipv4.ip_local_port_range 参数。带宽打满时，iftop 可以看到实时流量来源 IP；如果没有任何明显流量但负载很高，还要警惕网卡中断和驱动问题。
排查网络问题时，我特别推荐先看 sar -n DEV 1 或者 nload，把网卡吞吐量和丢包率拉出来看一眼。丢包率高要再看网卡错误计数 ip -s link show eth0，有时候网线或光模块松动会导致大量的 RX errors，这种问题代码层面是排查不出来的。
3.5 进程与系统服务异常：僵死、重启与开机自启
进程层面最常见的告警是“服务挂了”和“进程僵死”。先排查服务是怎么退出的：看 systemd 的状态 systemctl status 服务名，它会显示进程退出码和最近日志。关键的退出码里，137 基本意味着被 SIGKILL 杀掉（常见于 OOM 或被 docker kill 掉），143 是 SIGTERM 正常终止（可能是人为 stop 或应用收到终止信号自行退出）。
如果进程进入了 D 状态（不可中断睡眠），一般是在等待磁盘 IO 或内核资源，此时进程既不能被 kill 终止，也不能正常响应请求。用 ps aux | awk '$8 ~ /D/' 找出这些进程，再用 /proc/PID/stack 和 dmesg 看是不是磁盘异常或文件系统卡死。
服务偶发重启还会遇到“重启后不自动拉起”的坑。systemd 管理下，可以在 service 配置里加 Restart=always，但要配合 RestartSec 防止频繁重启导致无限循环。另外，很多基础服务本身会做进程守护，比如 Nginx 的 master 进程挂了 worker 会自动退出，靠 systemd 拉起 master；K8s 里则靠 Pod 的 liveness 探针决定是否重启容器。每一层的“重启机制”要搞清楚，否则你会看到现象是“服务一直重启”，但没有一层在真正负责恢复。
4. 从裸机到集群：K8s 与监控系统的告警协同排查
4.1 容器环境下的“节点异常”怎么查
现在很多业务都跑在 K8s 上，遇到告警后的排查路径从“登录服务器”变成了“先看集群状态”。节点 NotReady 是深夜最让人头疼的告警之一。通常我先执行 kubectl get nodes -o wide 定位出问题的节点，再登录节点看 kubelet 的状态：systemctl status kubelet。很有可能是磁盘压力过大触发了节点驱逐，或者容器运行时（containerd/docker）异常退出。
看到 Pod 一直 CrashLoopBackOff，我的标准动作是 kubectl describe pod Pod名 -n 命名空间，里面会写清楚上次退出的原因和容器事件。再用 kubectl logs Pod名 --previous 看上一次退出的日志。很多情况下 CrashLoop 的根源也是 Linux 层的问题，比如文件句柄用完、磁盘只读、内存 limit 太小被 OOM。容器被 OOM 杀掉时，kubectl describe 里会显示 OOMKilled，此时要去调整 Pod 的 resources.limit，而不是一味加大副本数。
排查容器内进程资源时，直接在 Pod 里执行 top 往往只能看到容器自身视角，要看宿主机全局数据应该用 kubectl top node 和 kubectl top pod，它们的数据来自 metrics-server。如果节点 CPU 已满但所有 Pod 的 CPU 都不高，要考虑是否是节点上的非 Pod 进程（比如 kubelet、containerd、node-exporter 等系统组件）或监控 agent 在消耗资源。
4.2 Zabbix 等监控系统本身也会“炸”
有段时间我处理过一个很曲折的告警：业务一切正常，但 Zabbix 不停报“Zabbix agent is not running”，最后发现是 agent 主机名配置错误导致数据上报不稳定。这说明排查告警时要带上监控系统本身。监控平台是工具，也是系统，它一样会被资源耗尽、网络不通、配置错误影响。
Zabbix 场景下，传统方案通过配置报警媒介实现钉钉/企业微信等 Webhook 推送。我自己的实践是先把告警脚本放在 /usr/lib/zabbix/alertscripts/ 下，改好媒介类型，然后在用户配置里把收件人绑定到对应媒介。刚开始没收到消息，排查后发现是脚本里的 Webhook URL 权限没配对。新版 Zabbix 7.0 的媒介配置更加模板化，用 Webhook 类型时可以直接在媒介配置页面填请求 URL、Header、Body，要注意测试按钮不会 100% 模拟真实告警触发后的上下文变量，最好在“测试”页面里填好具体的 {ALERT.SUBJECT} 和 {ALERT.MESSAGE} 变量再点测试。
另外，告警处理完之后，Zabbix 的告警条目通常不会自动消失。7.0 版本里手动确认/关闭告警的操作路径在“监测”页面选中事件，再点“确认”按钮并备注原因，这个操作既是对事件的状态管理，也是团队交接的有效记录。我建议值班人员处理完每个告警都追加备注，比如“已重启应用，观察中”，后续接手的人一眼就能看懂前因后果。
4.3 当监控趋势图和实际表现对不上时
另一种让人崩溃的场景是：监控显示 CPU 打满，但业务侧说没有流量；或者监控没有告警，业务却已经不可用。这种“对不上”多数来自采集器视角偏差。检查时先看监控项的采集周期和聚合方式，比如 Prometheus 的 rate 函数配合短时间窗口会把瞬时峰值磨平，Zabbix 内置监控项的“简单变化”或“差值”模式也可能掩盖短时间内的飙升。
我遇到过一次 CPU 告警和业务反馈完全对不上，后来发现是监控 agent 的采集进程自己耗尽了 CPU，等于监控到的“系统负载”其实是采集代理的故障。排查这种伪告警时，需要在主机上直接执行 ps aux --sort=-%cpu | head -5，看看占用 CPU 最高的进程里是否混入了 exporter、agent 之类的东西。如果监控 agent 频繁重启，也会产生断点，监控平台会顺着补点或误报，需要先处理 agent 的运行环境。
5. 让下一次告警“不炸”：收尾、复盘与告警治理
5.1 故障处理完，先完成三件收尾动作
告警恢复不等于故障结束。我自己的排障流程里，恢复业务之后还有三件事一定要做：第一，确认告警不会再短时间复燃，比如磁盘清理完要建立定时清理机制，而不是清完就完；第二，把处理过程中收集到的日志、命令输出、时间线整理到自己的记录里，避免下次重新踩坑；第三，检查是否遗留了临时的“救火”配置，比如为了快速恢复手动的防火墙放行、临时加大的日志级别，这些要尽快固化或回滚。
有个非常现实的建议：故障处理现场尽量不要在 SSH 终端里随手敲不清楚后果的命令。我见过有人为了清磁盘直接 rm -rf /var/log/，结果系统日志全没了，后期故障复盘两眼一抹黑。恢复操作一定要克制，能用 mv 把文件挪走再确认业务不受影响，就不要直接 rm。
5.2 告警质量决定排障效率，别再天天被狼来了
排障经验再丰富，也扛不住每天几百条无效告警轰炸。告警治理的核心是把“值得响应的信号”和“噪音”分开。阈值不是越灵敏越好，而是要结合业务周期。比如夜间业务低峰，CPU 偶尔冲到 80% 但持续不到一分钟就回落，就不该告警；反过来，连接数从 5000 涨到 6000 也许不吓人，但如果它连续涨了 30 分钟，即使绝对值不高也值得关注。所以我设置告警时会同时关注持续时间和趋势，而不是单看瞬间值。
另外，告警通知必须带上下文信息。一条有效的告警至少应该包含：主机 IP、监控项名称、当前值、阈值、触发时间、告警级别。如果只发“CPU high”这种标题，值班的人还是要再登录监控平台去查半天，响应效率自然低。Zabbix 的告警消息模板里可以引用 {HOST.NAME}、{ITEM.KEY}、{ITEM.LASTVALUE} 这些宏，发出来的消息就会清楚很多。
5.3 沉淀自己的 Linux 排障“作战手册”
最后说说我一直强调的文档沉淀。每个人的服务器环境不一样，网上教程再全面也不如你自己整理一份针对当前环境的作战手册。这份手册不需要很复杂，大致分四块：资产清单（IP、带外地址、账号权限归属）、常见告警处理流程（比如磁盘、CPU、内存、网络、进程，各写一条命令序列和判断标准）、历史故障复盘记录（时间、现象、根因、处理过程、后续改进）、重要变更记录。
我推荐把关键操作命令写在手册里而不是全靠脑子记，因为紧急时刻大脑会短路。手册本身我习惯用 Git 管理，改动有记录，每次故障复盘后随手更新，长期坚持下来，你会发现自己深夜被叫醒的次数越来越少。就算真有告警炸裂的夜晚，你也能打开手册，按图索骥，心里有底。
我在处理告警这件事上最大的体会是：它靠的不是神操作，而是流程和习惯。把每次救火都当成一次补全地图的机会，把“深夜被叫醒”变成“看一眼就知道怎么处理”，这个目标一点都不遥远。