10 个 Linux 命令，帮你快速定位 80% 的线上故障

线上故障排查最怕两件事：一是没有顺序，登录服务器后凭感觉执行命令；二是过早操作，看到磁盘满就删文件，看到进程异常就重启。前者会浪费故障窗口，后者会破坏现场，甚至把局部问题扩大成数据丢失或全站中断。

本文选取 10 个 Linux 常用命令，组成一条从整机到进程、从资源到日志的排查路径。它们不能覆盖所有故障，也不能替代应用监控、链路追踪和专业分析工具，但足以帮助初中级运维工程师快速回答几个关键问题：问题是否仍在发生，受影响的是 CPU、内存、磁盘还是网络，哪个对象最可疑，以及现有证据是否足以执行修复。

示例以常见的 systemd Linux 发行版为主。mpstat、pidstat、iostat 通常来自 sysstat 软件包；不同发行版、内核和工具版本的字段可能略有差异，应以本机 man 手册和实际输出为准。安装软件包会修改系统状态，生产环境应遵守变更规范，不要在故障高峰临时更换软件源或批量安装工具。

一、执行命令前先固定故障现场

开始前记录告警时间、主机名、业务实例、最近变更、监控图时间范围和当前处理人。确认自己登录的是正确环境：

hostnamectl
date --iso-8601=seconds

本文命令以只读采样为主，但只读不等于零开销。短周期采样、遍历大量进程、读取海量日志都会增加 CPU、I/O 或日志系统压力。应从轻量命令开始，限制次数和时间范围；不要把本文中的示例主机名、PID、设备名和时间直接复制到生产环境。

推荐顺序如下：先用 uptime 判断时间和负载，用 top 看当前热点，再用 vmstat、mpstat 区分资源类型；随后用 pidstat 定位进程，用 iostat 看块设备，用 ss 看网络连接；最后检查文件系统容量、服务日志和内核日志。

命令一：uptime——确认负载趋势和故障时间

uptime

示例输出：

 15:20:01 up 42 days,  3:18,  2 users,  load average: 12.40, 10.85, 6.20

uptime 给出当前时间、运行时长、登录用户数，以及 1、5、15 分钟 load average。示例中短周期负载高于长周期，说明负载近期在上升，但这还不能说明 CPU 已跑满。

Linux load average 主要反映可运行任务和不可中断睡眠任务的数量。CPU 密集计算会推高负载，磁盘、NFS 或其他内核等待也可能推高负载。判断时还要知道逻辑 CPU 数：

nproc
lscpu

持续负载明显高于逻辑 CPU 数通常表示排队加剧，但没有一个适合所有系统的固定报警倍数。服务类型、CPU 拓扑、任务状态和历史基线都会影响判断。负载低也不能证明业务正常：网络连接失败、服务退出或流量没有到达时，系统可能很空闲。

如果 uptime 显示刚重启不久，要立即核对变更和启动日志。短运行时长是事实证据，不代表一定发生了异常重启；还需用 journalctl --list-boots 和基础设施记录确认。

命令二：top——快速锁定当前资源热点

交互查看：

top

采集 10 次、每秒一次，并保存现场：

LC_ALL=C top -b -d 1 -n 10 > /tmp/top-$(date +%Y%m%d-%H%M%S).txt

写入前检查 /tmp 空间和 inode，避免诊断文件加重磁盘问题：

df -h /tmp
df -i /tmp

top 首部重点看 load average、任务状态、CPU 时间、内存和 swap；进程列表重点看 PID、用户、状态、CPU、内存、运行时间和命令。常见 CPU 字段包括 us、sy、id、wa、st，分别对应用户态、内核态、空闲、I/O wait 和虚拟机 steal。字段名称和显示模式受 procps-ng 版本与交互配置影响。

进程 %CPU 的分母要特别注意：在多核主机上，单个多线程进程可能超过 100%。这不代表监控错误。top 的交互模式切换也会影响显示，分析报告中应记录逻辑 CPU 数和工具模式。

按 H 可切换线程显示，或直接针对目标 PID：

PID=12345
top -H -p "$PID"

PID=12345 是占位符，必须换成已确认的真实 PID。top 只代表采样时刻，不能仅凭一帧认定根因。至少观察多个采样周期，并与告警时间、请求量和日志对齐。

命令三：vmstat——判断运行队列、换页和系统整体状态

vmstat 1 10

示例输出：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa st
10  0      0 642000  18000 820000    0    0    10    40 6200 18000 78 18  4  0  0

vmstat 第一行通常是自系统启动以来的平均值，实时故障应主要看后续行。

• r
  
  ：可运行任务数。持续高于逻辑 CPU 数，表明运行队列存在竞争。
• b
  
  ：不可中断睡眠任务数。持续上升常见于 I/O 或内核等待，但需要进一步取证。
• si
  
  、so：每秒从 swap 换入和换出的数据量。swap 已使用不代表当前正在频繁换页，必须看采样期间是否持续活动。
• bi
  
  、bo：块设备读入和写出速率，单位以本机版本说明为准。
• in
  
  、cs：每秒中断和上下文切换。绝对值需与同机型历史基线比较。
• us
  
  、sy、id、wa、st：CPU 时间分布。

典型组合比单字段更有价值：r 高、us 高、id 低，通常转向业务计算热点；b 和 wa 同时高，转向存储或不可中断等待；st 高的虚拟机需要结合宿主平台指标；si、so 持续活跃且延迟升高，说明内存压力可能在通过换页放大。

vmstat 的内存字段不能替代 /proc/meminfo 或 cgroup 统计。容器达到内存 limit 时，宿主机 free 仍可能很多。

命令四：mpstat——区分单核跑满和整机跑满

mpstat -P ALL 1 10

示例输出：

Average:     CPU    %usr   %nice   %sys  %iowait  %irq  %soft  %steal  %idle
Average:       0   96.00    0.00    3.00     0.00  0.00    0.50    0.00   0.50
Average:       1   18.00    0.00    4.00     1.00  0.00    1.00    0.00  76.00

示例说明 CPU 0 接近跑满，而 CPU 1 仍有余量。这可能是单线程热点、CPU 亲和性、软中断分布或应用调度方式造成的，需要继续检查进程和线程，不能直接通过扩容整机解决。

判断重点：

• %usr
  
   高：常见于业务计算、压缩、加密、序列化、垃圾回收等用户态工作。
• %sys
  
   高：检查系统调用、锁、网络包处理、频繁上下文切换或内核路径。
• %soft
  
   高：结合 /proc/softirqs、网卡包率、丢包和中断亲和性分析。
• %iowait
  
   高：表示 CPU 空闲且有未完成块 I/O 的时间，不能直接等同于磁盘利用率。
• %steal
  
   高：虚拟 CPU 在等待宿主机调度，需要云平台或虚拟化平台侧证据。

只看所有 CPU 平均值会掩盖单核瓶颈。反过来，某个 CPU 短时 100% 也不一定导致业务故障，应结合线程热点和请求延迟。

命令五：pidstat——把资源异常定位到进程和线程

综合采样 CPU、缺页、I/O 和上下文切换：

pidstat -u -r -d -w 1 10

只看指定进程及其线程：

PID=12345
pidstat -t -u -r -d -w -p "$PID" 1 10

pidstat 适合回答：“整机异常期间，究竟哪个进程持续消耗资源？”-u 查看 CPU，-r 查看缺页和内存，-d 查看 I/O，-w 查看上下文切换，-t 展开线程。不同 sysstat 版本的可组合参数和字段存在差异，执行前可查看 pidstat --help 或手册。

不要仅按一次 %CPU 排名判定根因。高 CPU 进程可能正在处理正常流量，真正异常的是流量突增或下游超时重试。应同时检查进程启动时间和完整参数：

ps -p "$PID" -o pid,ppid,user,stat,psr,pcpu,pmem,rss,vsz,etime,lstart,cmd
cat"/proc/$PID/status"
cat"/proc/$PID/limits"

命令行参数可能包含口令、令牌或连接串，保存和分享诊断文件前必须脱敏。进程 RSS 还可能包含共享页，多个进程 RSS 不能直接相加当作总内存。精确分析可查看 /proc/$PID/smaps_rollup，但进程退出后这些信息无法补采。

如果某线程持续高 CPU，应使用对应运行时的线程转储或采样工具建立证据。例如 Java 可用 jcmd PID Thread.print -l，但附加诊断工具有短时开销，且输出可能包含敏感类名和路径，应先在单实例评估。

命令六：iostat——判断块设备是否成为瓶颈

iostat -xz 1 10

-x 显示扩展统计，-z 隐藏采样期间无活动的设备。第一组设备数据可能是自启动以来的平均值，实时分析重点看后续区间。

常见字段包括读写 IOPS、吞吐、平均请求大小、队列、读写等待时间和设备忙碌程度。sysstat 版本不同，可能显示 r_await、w_await、aqu-sz、avgqu-sz、%util 等不同字段。

证据判断不能只看 %util：

• 对传统单队列磁盘，%util 接近 100% 常提示设备繁忙。
• 对 NVMe、多队列设备、RAID、SAN 和云盘，设备能并行处理请求，%util 不能单独代表饱和。
• await
  
   是请求从排队到完成的平均时间，必须和设备类型、业务 SLO、IOPS、吞吐及队列共同判断。
• 应用写慢也可能由文件系统、日志同步、存储网络或远端服务导致，不能把所有 I/O 问题都归因于本地磁盘。

继续定位进程可以配合：

pidstat -d 1 10

如果 iostat 显示延迟上升，内核日志又有超时、reset 或文件系统错误，证据更强。此时不要先执行清缓存、卸载文件系统或重启节点，这些操作可能扩大影响并丢失现场。

命令七：ss——检查监听、连接状态和队列

查看监听端口及进程：

ss -lntp

查看 TCP 状态汇总：

ss -s

查看目标端口的 TCP 连接，以下端口必须替换为真实服务端口：

PORT=443
ss -ntp "sport = :$PORT"

非 root 用户可能看不到其他用户进程信息。ss 可帮助确认服务是否监听、监听在哪个地址、当前连接状态和 socket 队列。监听行中的 Recv-Q、Send-Q 与已建立连接行的语义不同，不能统一解释为“网络积压”。监听 socket 的队列信息可辅助判断 accept 队列，已建立 TCP 连接则反映接收或发送相关队列，具体语义以 ss(8) 与内核实现为准。

统计连接状态时不要用无限制的复杂管道扫描所有连接并高频执行，在连接数巨大的主机上会增加开销。可以先用 ss -s 汇总，再围绕端口和地址缩小范围。

常见判断：

• 没有监听：检查服务状态、绑定地址、启动日志和配置，而不是先改防火墙。
• SYN-RECV
  
   大量增长：可能存在突发连接、上游重试、攻击或 accept 路径瓶颈，需要结合包率、SYN cookies、负载均衡和应用处理能力。
• TIME-WAIT
  
   多：它本身是 TCP 正常状态，需结合新建连接率、端口范围、连接复用和业务影响，不可直接清理。
• CLOSE-WAIT
  
   持续积累：通常提示本端应用未及时关闭已被对端关闭的 socket，应定位进程和代码路径。

修改防火墙、内核 TCP 参数或连接跟踪配置都属于高风险操作。没有包捕获、计数器和路径证据时，不要用放宽参数掩盖应用问题。

命令八：df——检查容量、inode 和挂载点

查看文件系统容量和类型：

df -hT

查看 inode：

df -i

磁盘“满”有两种常见表现：空间用尽和 inode 用尽。大量小文件可能导致 df -i 达到 100%，即使 df -h 仍有空间；应用会表现为无法创建文件、日志写入失败或部署解压失败。

还要确认路径实际位于哪个挂载点：

findmnt -T /var/log

df 和目录统计不一致时，检查是否有已删除但仍被进程打开的文件：

lsof +L1

lsof +L1 在大型主机上可能遍历较多对象，故障高峰应限定用户、进程或路径。文件被删除后，只要进程仍持有文件描述符，空间通常不会释放。不要因此直接重启进程，先确认该文件属于哪个服务、是否能安全重新打开日志，以及是否存在数据未刷盘风险。

磁盘清理是高风险操作。影响范围可能包括应用数据、审计日志、数据库 WAL/binlog、容器层和系统启动。执行前必须确认文件用途、持有进程、保留策略、备份和恢复方法；先生成候选清单并人工审核，使用应用或日志系统官方轮转机制灰度处理。禁止用未经限定的 rm -rf、find ... -delete 或截断命令直接清理生产目录。

命令九：journalctl——把资源现象和服务事件对齐

查看指定服务最近 30 分钟日志：

SERVICE=example.service
journalctl -u "$SERVICE" --since '-30 min' --no-pager

SERVICE 是占位符，必须替换为真实 systemd 单元名。查看带精确时间的错误优先级日志：

journalctl -u "$SERVICE" --since '2026-07-10 14:00:00' --until'2026-07-10 14:30:00' -p err --no-pager -o short-iso-precise

日期是示例，要替换为告警窗口。-p err 只显示错误及更高优先级消息，排查时不应只看错误级别，因为关键上下文可能记录为 warning 或 info。建议先限定时间和单元读取完整上下文，再用关键字筛选。

查看服务状态与本次启动日志：

systemctl status "$SERVICE" --no-pager
journalctl -u "$SERVICE" -b --no-pager

重点对齐：进程启动退出、配置加载、依赖连接失败、超时、重试、OOM、健康检查和发布操作。日志中的一条异常不等于根因。例如“数据库连接超时”可能由数据库故障、网络丢包、连接池耗尽或应用线程阻塞导致，必须与 ss、延迟指标和依赖侧日志交叉验证。

journald 可能未启用持久化，日志也可能已轮转。没有日志只能说明当前数据源没有记录，不能证明事件未发生。读取和导出日志时还应注意凭证、用户数据和请求内容的脱敏。

命令十：dmesg——确认内核、OOM、设备和文件系统异常

读取可读时间戳的内核环形缓冲区：

dmesg -T --level=emerg,alert,crit,err,warn

dmesg -T 的人类可读时间可能受系统挂起、恢复或时钟变化影响。需要与日志平台精确对齐时，优先结合 journalctl -k -o short-iso-precise：

journalctl -k --since '-2 hours' --no-pager -o short-iso-precise

常见关注项包括：

• Out of memory
  
  、oom-kill、Killed process：确认内核 OOM 或 memory cgroup OOM。
• 块设备 timeout、reset、I/O error：结合 iostat 和存储侧指标分析。
• 文件系统只读、journal error、metadata error：立即评估数据一致性和写入影响。
• 网卡 link down/up、驱动 reset、队列异常：结合接口统计和交换机/云平台日志。
• soft lockup、hung task、RCU stall：可能涉及 CPU 卡死、内核等待或驱动问题，需要保留完整上下文和内核版本。

内核日志权限通常受 kernel.dmesg_restrict 控制。不要为了读取方便临时降低安全参数；应通过授权账户或既定日志平台获取。看到硬件或文件系统错误后也不要直接重启，因为重启可能暂时隐藏症状、触发更长恢复过程或丢掉环形缓冲区证据。

二、把 10 个命令串成一次完整排查

假设监控报告接口超时，同时节点负载升高，可以按以下思路闭环：

1. uptime
   
    确认负载近期上升，并记录主机运行时长。
2. top
   
    观察 CPU、内存、任务状态，发现是整机 CPU 忙还是存在大量 D 状态任务。
3. vmstat
   
    用 r、b、wa、si/so 区分 CPU 排队、I/O 等待和换页。
4. mpstat -P ALL
   
    判断是单核还是多核、用户态还是内核态。
5. pidstat
   
    定位持续异常的进程与线程，而不是依赖一次排名。
6. iostat
   
    验证块设备队列和延迟是否与故障同窗。
7. ss
   
    确认监听、连接状态和 socket 队列，排除请求没有到达或连接堆积。
8. df -hT
   
   、df -i 检查容量、inode 和真实挂载点。
9. journalctl
   
    对齐应用退出、重试、依赖超时和发布信息。
10. dmesg
    
     或 journalctl -k 检查 OOM、设备、文件系统和内核异常。

每一步都应产生“继续查什么”的判断。例如，vmstat 显示 b、wa 高，iostat 同时显示目标设备等待时间和队列上升，内核日志又出现该设备超时，那么存储路径证据逐渐闭合。若只有 iostat %util 高，而应用延迟、队列和日志均正常，则证据不足以定性。

三、三类常见误判

误判一：load 高就是 CPU 不够

load 包含不可中断睡眠任务。必须结合 mpstat 的 CPU 时间和 vmstat 的 r、b 判断。若 CPU 大部分空闲但 b 高，扩容 CPU 通常不能解决问题。

误判二：内存 free 很少就是内存泄漏

Linux 会利用内存做缓存。应关注 MemAvailable、进程 RSS/匿名内存、cgroup 限额、PSI、swap 活动和时间趋势。进程被 OOM kill 后释放内存，故障后的 free 也不能反推故障前状态。

误判三：端口不通就是防火墙

先用 ss -lntp 确认服务是否监听、绑定地址是否正确，再检查路由、负载均衡、安全组、防火墙和对端返回路径。直接放开端口可能扩大安全暴露，且无法解决服务未监听或应用阻塞。

四、执行修复前必须满足的证据条件

命令帮助定位，不代表有权立即修复。涉及删除数据、重启服务、清理日志、修改内核参数、防火墙、数据库参数、Docker/Kubernetes 资源、集群扩缩容或主从切换时，至少补齐以下内容：

• 影响范围
  
  ：明确主机、实例、连接、数据、下游和冗余能力，判断是否会触发选主、重调度或流量转移。
• 执行前检查
  
  ：确认健康副本、剩余容量、在途任务、错误率、延迟、依赖状态和操作权限。
• 备份方式
  
  ：保存原配置、版本化清单、关键日志和诊断数据；有状态服务按对应产品官方流程做一致性备份。
• 灰度或 dry-run
  
  ：先在测试环境、单实例或少量节点验证；支持 dry-run 的工具先检查变更对象，但 dry-run 不能替代真实业务验证。
• 验证方式
  
  ：同时验证资源指标、服务健康、错误率、吞吐、P95/P99 延迟和关键业务功能，不能只看命令退出码。
• 回滚方案
  
  ：准备原配置、原制品和回切路径，定义触发回滚的指标阈值和执行人。

重启尤其需要谨慎。它可能释放资源、清空连接和暂时恢复服务，但同时会丢失 /proc 现场、内存对象和部分环形日志。若必须重启，先摘流、保存证据、确认健康副本和剩余容量，并只灰度处理一个实例。kill -9 不能让进程优雅清理资源，不应作为常规手段。

五、修复后的验证和复盘

修复完成后，重新执行同一组采样，并使用与故障前一致的时间窗口和统计口径。至少验证：

• load、运行队列、CPU 类型、换页和 I/O wait 是否恢复到历史基线。
• 目标进程 CPU、内存、I/O 和上下文切换是否稳定。
• 磁盘等待、队列、容量、inode 和内核错误是否恢复。
• 监听和连接状态是否正常，流量是否真实恢复，而不是因摘流导致资源下降。
• 错误率、吞吐、P95/P99 延迟和业务功能是否达标。
• 修复是否把压力转移到其他节点、磁盘或下游服务。

复盘中记录原始命令、采样时间、关键输出、变更时间线、直接原因、根因、修复和回滚结果。不要只写“CPU 高，重启恢复”或“磁盘满，清理完成”。这样的记录无法帮助下一位值班工程师判断同类问题，也不能证明操作安全。

这 10 个命令的价值不在于记住所有参数，而在于建立固定顺序：先确认时间和整体状态，再区分资源类型，随后定位对象，最后用服务日志和内核日志闭环。排障效率来自证据逐步收敛，而不是命令执行得多。只要每一步都能回答“我看到了什么、它能证明什么、还不能证明什么”，大多数常见线上问题就不会停留在猜测阶段。

版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除

想了解更多干货，可通过下方扫码关注

可扫码添加上智启元官方客服微信👇