FFFire小火看过凌晨两点机房跳动的红色告警的人，大概都有过那种“脑子一片空白”的瞬间。监控面板上一排排变红的数字，钉钉/企业微信群里连绵不绝的艾特，再加上测试同事的一句“网站打不开了？”——多数故障的起点，其实是运维本人先“CPU过载”。我干运维这行十来年，处理过大大小小几百起线上事故，想跟你分享一个特别朴素的道理：告警本身不可怕，可怕的是没有一套按部就班的排查流程。 这份Linux故障排查“作战地图”，就是我这些年被炸出来的经验总结，希望它能帮你从“看见告警就心惊肉跳”进化成“收到告警先按流程走一遍”。
1. 深夜告警的“黄金三分钟”：先看态势，不要急着登录服务器
1.1 告警不都是“火警”，先花一分钟判断真伪和级别
深夜收到告警，很多新手的第一反应是赶紧ssh登录服务器，然后一连串命令敲下去：free -g、top、df -h，敲完也不知道问题到底在哪。这里我想提醒你一个反直觉的操作：接到告警后的第一件事，不是登录，而是看监控面板的时间轴和告警详情。
告警到达时，你先问自己三个问题：第一，这个告警持续多久了？是刚刚发生还是已经持续了半个小时？第二，告警的级别是什么？是ERROR还是WARNING？第三，监控面板上的曲线是在持续上涨，还是已经出现了转折点？我遇到过不少次，告警发出来的时候系统其实已经自我恢复了，或者只是监控项配置不合理导致的偶发抖动。如果这个时候你手忙脚乱连上去跑命令，反而可能踩到真正的雷。
我自己的习惯是手机上看一眼监控App的趋势图，确认是断崖式暴跌还是缓慢攀升。断崖式暴跌往往出现在网络分区、进程挂掉等场景，需要立刻介入；缓慢攀升则可能是流量自然上涨或内存泄漏，可以多观察几分钟。
1.2 搞清“谁在报警”比“怎么处理”更重要
运维圈有句话叫“告警风暴比故障本身更可怕”。尤其是Zabbix这类监控系统，一个底层基础设施出问题，经常会连带触发几十条主机、服务、依赖关系的告警。举个真实的例子：某次凌晨vSphere宿主机证书过期，结果一晚上涌进来四五十条“Zabbix agent unreachable”和“HTTP服务超时”的告警，实际根子全在证书上。
所以收到告警千万别陷入“逐条消灭”的陷阱。正确的打开方式是：先找到告警的根因入口，看有没有共同的父节点。如果是数据库挂了，那依赖数据库的所有应用告警都是它的子节点；如果是网络交换机端口故障，那该端口下的所有主机和虚拟机告警全是连带告警。我们的目标是找到那棵“告警树的根”，而不是修剪每一片树叶。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 看懂 load average 背后的三重含义：你的系统到底是不是真的“累”了
2.1 load average 不等于 CPU 使用率
看到服务器负载告警，大家第一反应就是去看 top 输出里的 load average。这里我先泼一盆冷水：load average 高，并不意味着 CPU 就一定忙。在Linux里面，load average 统计的是处于可运行状态（R状态）和不可中断睡眠状态（D状态）的进程平均数量。也就是说，它涵盖了等待CPU调度的进程，也涵盖了等待I/O（磁盘、网络）的进程。
这就产生了一个非常经典的误判场景：大量进程阻塞在磁盘I/O上，CPU本身闲置率很高，但 load average 可能飙到四五十甚至上百。如果你按照“CPU超载”的思路去排查，加配置、扩容，结果方向完全跑偏，问题自然解决不了。
2.2 用 vmstat 快速拆解负载构成
要拆解 load average 到底是谁撑起来的，我建议你养成一个肌肉记忆：登录服务器后，先执行 vmstat 1 5，输出如下：
bash复制procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 10240 589312 1234 8388608 0 0 0 124 1200 3400 12 3 82 3 0
这里重点看三列：r（运行队列）、b（阻塞在I/O上的进程数）、wa（I/O等待时间占比）。如果 r 值远大于逻辑核数，说明是CPU资源不足；如果 b 列明显高并且 wa 超过20%，说明瓶颈在I/O而非CPU；如果 r 和 b 都不高，但load很高，那很可能是大量进程处于不可中断的D状态，需要往更深层的硬件或者内核层面排查。
2.3 当 D 状态进程堆积：SRE 最头疼的不可中断阻塞
有时候你会看到 vmstat 输出里 b 列居高不下，wa 倒是不算高，进程出现大量D状态。这种状态在Linux内核中表示进程正在等待某种系统资源（一般是同步I/O）返回，你连 kill 都没法直接杀掉它，因为它不响应常规信号。此时排查方向就得转到：是不是NFS文件系统挂掉了？是不是iSCSI链路中断了？是不是底层存储阵列出现了慢盘？我遇到过磁带库驱动器故障导致整个备份进程D状态堆积的案例，排查到最后才发现是存储设备的SCSI指令超时时间设置得过于激进。
3. 像法医解剖一样定位 CPU 异常：从 top 到 perf 的分层取证
3.1 先看“最卷”的几个进程：top 排序的艺术
确认瓶颈在CPU后，接下来就是定位“谁在吃CPU”。top 命令默认按CPU使用率排序，但有时候会被一些短时进程蒙蔽双眼。我的习惯是进入 top 后按 P 键把CPU排序做一次确认，再按 M 键看看内存占用排序，来回切换几次，观察头部进程有没有反复横跳。如果某个进程的名字反复出现且CPU占用稳定在较高水平，十有八九就是它了。
注意：top 里看到的 %CPU 数值，在多核服务器上可能超过100%。比如一个进程占满2个核，显示可能是200%。这个要看清楚，别被吓到。
3.2 用户态CPU高和内核态CPU高，排查思路完全不同
拿到CPU占用高的进程PID之后，下一步要区分它是耗在用户态（us）还是内核态（sy）。用 top -Hp <PID> 可以查看进程内部线程的CPU占用，结合 pidstat -t -p <PID> 1 能更清晰地看到线程级别的消耗。
如果耗在用户态，通常是应用自身的运算逻辑、GC垃圾回收或正则匹配等导致的。Java服务的话可以用 jstack 抓线程快照、用 MAT 分析堆转储；如果是Python脚本，那就审查代码里有没有死循环或者低效的字符串处理。
如果耗在内核态，就需要引起更高的警觉。跑一下 strace -cp <PID> 看看系统调用的统计分布，往往会发现是频繁的文件打开/关闭、系统调用参数错误导致的内核路径浪费，或者是频繁的内存分配页表操作。再进一步，可以用 perf top 直接看内核热点函数，定位到具体模块。
3.3 一次线上 CPU 排障的完整命令链路
我拿一次真实的 CPU 告警处理做示范，完整跑一遍命令顺序：
bash复制# 1. 确认负载和CPU概况
top
# 2. 按CPU排序，找到嫌疑进程
# 按 P 键，记录下 PID，比如 12345
# 3. 查看该进程的线程级CPU消耗
top -Hp 12345
# 4. 用 pidstat 持续观察5秒
pidstat -t -p 12345 1 5
# 5. 如果是Java进程，抓线程快照
jstack 12345 > /tmp/jstack_$(date +%F_%H%M).txt
# 6. 如果是普通C/C++或Python，用strace看系统调用统计
strace -cp 12345
# 7. 内核态热点确认
perf top -p 12345
这一套下来，90%的CPU问题都能定位到具体函数或代码层面。剩下的10%，往往需要结合业务日志和变更记录综合判断，比如发布系统刚上线的版本引入了死循环。
4. 打破“磁盘伪满”的盲区：删除文件后空间依然爆红的实战复盘
4.1 曾经赔上一整夜的一场事故
有一年我在论坛上看到有人求助：“df -h 显示根分区使用率95%，但 du -sh / 一看所有目录加起来还不到50%，怎么回事？”很多人回帖说查 find / -xdev -type f -size +1G 看看有没有大文件，最后他查来查去也没找到。这就是典型的**“进程占用已删除文件”**场景。
当时他执行了 rm -rf /var/log/nginx/access.log，想着释放空间，但是有个 nginx worker进程还一直持有这个已经被删除的文件句柄。所有写入都进了这个无名的文件空洞里，由于目录项已经没了，du 自然看不出来，但磁盘空间实实在在地被占着。
4.2 正确的排查与解决步骤：lsof + fuser 组合拳
遇到 df 和 du 结果不一致的情况，排查步骤非常简单，但很多人因为“不知道”，白白熬了一夜：
bash复制# 1. 查看所有deleted状态但仍被进程占用的文件
lsof +L1
# 2. 根据输出确认哪些进程占用了已删除的文件
# 例如输出显示 nginx PID 30841 持有 /var/log/nginx/access.log (deleted)
# 3. 不想重启主服务的话，把日志句柄释放一下
# 平滑重载nginx，让它重新打开日志文件
nginx -s reload
# 4. 如果具备实施条件，且进程本身无状态，可以重启进程
systemctl restart nginx
# 5. 删完之后再次确认空间是否释放
df -h
这个方法不仅适用于nginx日志，像Java应用输出到已删除的 gc.log、数据库的 binlog、容器运行时日志等，都会出现类似的情况。以后看到磁盘告警而 du 查不出来，先别急着翻 /var 目录逐层找，直接执行 lsof +L1。
4.3 inode 耗尽：磁盘空间很低却写不进文件的另一个反向陷阱
与磁盘空间“伪满”相对的，是inode耗尽。df -h 显示空间还有大量剩余，但应用报错“No space left on device”，这通常是目录下的小文件数量达到了上限。使用 df -i 查看inode使用率，再用 for i in /path/to/dir/*; do echo $i; done | wc -l 统计一下对应目录下的文件数量，找到垃圾小文件堆满的目录后清理即可。
比较常见的是 /tmp 目录未做定时清理、PHP/Java框架生成的临时会话文件过多、或者某次程序bug导致目录下不断创建缓存文件。我最夸张的一次是遇到一个 rabbitmq 的持久化目录里堆积了上百万个未消费的消息文件，直接撑满inode，服务完全不可用，最后通过临时增加inode容量并调整消息TTL策略解决的。
5. 当“告警系统本身”开始捣乱：屏蔽失效与误报如何反向定位
5.1 告警屏蔽不生效，问题出在“作用域”和“时间窗口”
很多运维用FlashDuty或Zabbix做告警管理时，都会踩到同一个坑：明明配置了屏蔽规则，告警还是照样发到手机里。我说句公道话，这大多数时候不是工具BUG，而是用户对屏蔽作用域的理解有偏差。
先说作用域，默认的屏蔽通常只对当前主机名或IP的精确匹配生效。如果你的告警来自某个模板继承的监控项，而监控项是按 标签 或 宏 来正则匹配主机分组的话，简单地在告警详情页上点屏蔽，往往只屏蔽了一条历史告警，下一次新触发的告警依然会第一时间通知你。正确做法是去监控模板里找到对应的触发器，按 正则表达式 添加维护期间的例外条件。
再说时间窗口。Zabbix的维护模式默认是“收集数据但不发送通知”，但它只对“进入维护状态之后新产生的告警”生效。如果告警在进入维护模式前已经处于problem状态，Zabbix默认不会自动恢复不发送通知，你需要在维护模式配置里勾选“抑制所有相关问题”之类的选项。
5.2 证书类告警的“拖延症陷阱”：vSphere证书与过期问题的传染效应
热搜词里有一条“vsphere证书状态告警”，看起来平平无奇，但这类证书告警如果处理不及时，会像多米诺骨牌一样压垮整个虚拟化平台。我自己处理过一个案例：某vCenter自签证书还有一个月过期，告警发了一周没人搭理，结果证书正式过期当天，ESXi主机之间的HA通信全部中断，虚拟机的在线迁移直接失败，业务部门早上纷纷反馈系统卡顿。
遇到这类告警我的原则是：证书类告警一律不等，立即提流程处理。 它不像磁盘空间，可以撑几天，证书一旦过期就是硬故障。如果是自签证书，把有效期直接调到十年，减少后续的续签频率；如果是普通证书，必须建立证书到期日历化提醒，至少提前一个月申请替换。
提示：
openssl x509 -enddate -noout -in /etc/ssl/certs/你的证书.crt可以快速查看证书到期时间，排查时用起来非常顺手。
5.3 Zabbix钉钉Webhook故障排查：告警没收到不一定是你配置错
如果你用的是Zabbix 7.0，而且正在折腾“钉钉Webhook媒介”，我会建议你先构建一个“最小可用告警链”：先在Zabbix前端配置一个简单的触发器（比如 last(/ping/ping)<1），再手动触发或等待它恢复，去查看“报表”→“动作日志”里有没有报错。大部分Webhook告警发不出去，原因集中在三个方面：
第一，自定义脚本里的Secret没有正确加密，钉钉机器人要求加签，很多人直接把secret明文写在脚本里，被钉钉接口拒掉了；第二，Zabbix服务器的出网代理或防火墙规则拦截了对 oapi.dingtalk.com 的访问，curl一下 https://oapi.dingtalk.com/robot/send?access_token=xxx 能通才说明网络没问题；第三，脚本执行权限不足，Zabbix用 zabbix 用户运行AlertScripts脚本，如果脚本没有给到对应权限，也不会执行报错，但前端看不到详细信息。
6. 排查完之后，必须要做的“战利品登记”：把今晚踩的坑变成明天省的时间
6.1 建一个“故障处理时间线”Word文档或Wiki页面
处理完故障、告警恢复之后，大多数人会直接去睡觉，这是极其错误的。深夜处理完故障后，大脑正处于峰值状态，很多细节还非常清晰，第二天起来再回忆，很多命令参数和输出结果就已经模糊了。 我的习惯是花20分钟，打开一个固定模板的文档，把下面几项填好：
- 故障开始与恢复的时间点（精确到分钟，方便复盘时对齐监控曲线）
- 告警的内容与触发前的异常行为
- 排查过程中每个关键命令的发现（不要求写完整输出，但一定要记录关键数值）
- 最终定位到的根因（用一句说清楚）
- 临时处置的手段与彻底治理的方案
- 是否需要升级给其他团队（比如网络组、存储组）
这份文档的价值会随时间放大。半年之后你再遇到同类问题，直接搜关键词就能看到当年的解决路径，不用重新从零开始。我手机上至今保留着一个“SRE应急速查表”的笔记，记录的就是各种资深的排查经验，可以说它比任何工具书都有用。
6.2 从“救火队员”到“防火专家”：最少需要五个面向
单靠一个个case积累，成长速度太慢。要把故障排查能力系统化，建议你围绕以下五个能够面向来建立自己的知识库：
| 面向 | 核心问题 | 常用工具与思路 |
|---|---|---|
| 系统资源 | CPU、内存、磁盘、I/O谁先扛不住了？ | top、vmstat、iostat、sar、dstat |
| 网络链路 | 连通性ok但质量差，还是压根不通？ | ping、telnet、traceroute、ss、tcpdump |
| 应用进程 | 进程还在吗？线程卡死还是资源泄漏？ | ps、top -Hp、jstack、gdb、strace |
| 日志与依赖 | 应用日志报了什么错？底层用到的服务是否正常？ | journalctl、tail -f、logrotate、dmesg |
| 变更与发布 | 出问题之前改了什么配置或发了什么版本？ | Git提交记录、部署平台时间戳、配置变更记录 |
有了这个框架，你收到任何告警都可以套进去：先分门别类，再层层深入。最怕的是没有框架，凭感觉乱试，一会儿敲个 top，一会儿看下日志，最后不了了之。
6.3 自动化你的“知识点”：把常用排查动作固化为一个小工具
最后聊一个进阶玩法。当同类告警第三次出现时，你就应该考虑把它固化成脚本或者工具了。比如我写过一个小脚本 diag.sh，一旦检测到系统负载超过5，会在60秒内自动执行一连串命令并把结果写入 /tmp/diag_$(date).log：
bash复制#!/bin/bash
LOG=/tmp/diag_$(date +%F_%H%M).log
{
echo "===== TIME ====="; date
echo "===== UPTIME ====="; uptime
echo "===== TOP CPU (5s) ====="; top -b -n 1 | head -30
echo "===== VMSTAT ====="; vmstat 1 5
echo "===== IO STAT ====="; iostat -x 1 3 | tail -30
echo "===== CONN STATE ====="; ss -s
echo "===== DSTATE PROCS ====="; ps -eo state,pid,cmd | awk '$1=="D"'
} >> "$LOG"
这样即使你人在床上，半个小时后打开这个日志文件，也能知道当初深夜告警炸裂时系统到底发生了什么。而且这些一手证据对第二天写复盘报告、和开发battle根因，都是利器。
遇到告警不要慌，按着“态势感知 → 指标拆解 → 进程定位 → 日志佐证 → 变更与文档”这条链路走，绝大多数故障都能在一个小时内收网。希望这份“作战地图”能成为你值班腰带上最趁手的一件装备。