1. 从一台卡住的服务器说起为什么命令行的基本功比想象中重要很多人第一次接触Linux都是从图形界面开始的。点点鼠标、拖拖文件感觉和用普通电脑没什么两样。但真正到了生产环境尤其是远程连上一台没有桌面环境的服务器时你会发现手里能用的只有一行黑底白字的终端。这时候命令行的熟练程度直接决定了你解决问题的速度。我见过不少刚入行的朋友遇到服务器响应慢、磁盘满了、进程杀不掉这类问题第一反应是重启。重启确实能解决一部分问题但它掩盖了根因下次还会再犯。而真正能定位问题的往往是几条看起来不起眼的命令——top、df、iostat、ss、journalctl。这些命令不需要你背下所有参数但你必须知道在什么场景下该用哪一个以及输出结果里哪些数字是关键的。这篇内容面向的是有一定Linux基础、但还没形成系统排查思路的读者。我会按照信息探查→资源监控→故障定位→恢复验证这条主线把日常运维中最常用的命令串起来讲。每个命令我都会说明它解决什么问题、输出怎么看、有哪些容易踩的坑。你不需要死记硬背跟着场景走一遍自然就记住了。提示本文所有命令均在主流发行版如Debian系和RHEL系上验证过部分命令在不同发行版中参数略有差异我会在涉及的地方特别标注。2. 系统信息探查先搞清楚自己在什么环境里在动手排查任何问题之前你得先知道这台机器是什么系统、什么内核、装了哪些工具。这就像医生看病要先问诊一样不了解环境就乱敲命令很容易得出错误结论。2.1 发行版与内核版本一切判断的起点最基础的三条命令是uname -a、cat /etc/os-release和hostnamectl。uname -a输出内核版本、主机名、架构等信息其中内核版本决定了你能用哪些新特性。比如cgroup v2需要较新的内核如果你在排查容器资源限制问题第一步就是确认内核版本。uname -a # 输出示例Linux web-node-01 5.15.0-91-generic #101-Ubuntu SMP ... x86_64 GNU/Linuxcat /etc/os-release则告诉你发行版名称和版本号。这个信息很关键因为不同发行版的包管理命令、服务管理方式、默认配置文件路径都不一样。我遇到过有人在CentOS上找apt命令找了半天没找到其实就是发行版搞混了。cat /etc/os-release # 输出示例NAMEUbuntu VERSION22.04.3 LTS ...hostnamectl是systemd体系下的命令一条就能同时看到主机名、操作系统、内核、架构、虚拟化类型。虚拟化类型这一项特别有用——如果显示KVM或VMware说明是虚拟机显示docker或lxc说明你在容器里。容器里很多命令的行为和物理机不同比如free看到的内存是宿主的还是容器的需要特别注意。2.2 硬件资源速查CPU、内存、磁盘一眼看清lscpu比cat /proc/cpuinfo可读性好得多它会汇总显示CPU架构、核心数、线程数、主频、缓存大小。重点关注CPU(s)和Thread(s) per core这两个数字相乘才是逻辑CPU总数。很多性能调优参数比如Nginx的worker_processes都依赖这个数字。lscpu | grep -E ^(CPU\(s\)|Thread|Core|Socket|Model name)内存方面free -h是最常用的。但要注意Linux的内存管理逻辑是空闲内存不用白不用所以free列显示很小是正常的真正要关注的是available列。如果available持续低于总内存的10%才说明内存紧张。free -h # 重点关注 available 列而不是 free 列磁盘信息用lsblk和df -h配合看。lsblk展示块设备的树状结构能看出磁盘分区和挂载点的对应关系df -h则显示每个挂载点的使用率。这里有个常见误区df看到的使用率和du统计出来的不一致。原因通常是文件被删除但进程还在持有句柄空间没有真正释放。这种情况用lsof | grep deleted就能找到元凶。2.3 网络配置与连通性别急着ping先看链路网络排查的第一步不是ping而是ip addr和ip route。ip addr看本机网卡和IP地址ip route看路由表。如果路由表里没有默认网关那ping任何外网地址都不会通这时候去查DNS是白费功夫。ip addr show ip route show # 确认默认路由是否存在default via 192.168.1.1 dev eth0确认链路层没问题后再用ping测试连通性。但要注意很多云服务器默认禁ping所以ping不通不代表网络有问题。更可靠的测试是curl -I或nc -zv指定端口。比如测试到某台服务器的SSH端口是否可达nc -zv 192.168.1.100 22 # 输出Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!DNS解析问题用dig或nslookup排查。dig short example.com直接返回解析结果干净利落。如果解析慢可以用dig trace看整个解析链路卡在哪一步。注意ip命令属于iproute2包老系统上可能只有ifconfig和route。建议尽早熟悉ip系列命令因为net-tools已经停止维护多年了。3. 资源监控与性能基线知道正常长什么样才能发现不正常排查故障最大的难点不是修复而是判断哪里不对。如果你不知道系统正常时的指标范围看到任何数字都会觉得可疑。所以建立性能基线是运维的基本功。3.1 CPU使用率别被100%吓到top是最经典的实时监控工具但它的输出信息量很大新手容易看花眼。我建议重点关注这几行load average、%Cpu(s)、以及按P排序后的进程列表。load average的三个数字分别代表1分钟、5分钟、15分钟的平均负载。判断负载是否过高要和逻辑CPU数量对比。比如4核CPU负载持续在4以上就说明有压力了。但负载高不一定是CPU忙也可能是IO等待。这时候要看%Cpu(s)行里的waIO等待百分比。如果wa很高而us用户态不高说明瓶颈在磁盘IO不在CPU。top -bn1 | head -20 # -b 批处理模式-n1 只刷新一次适合脚本采集htop是top的增强版支持彩色显示、鼠标操作、树状进程视图。如果系统里没装用包管理器装一下就行。但生产环境不一定允许你随便装软件所以top的基本功还是要扎实。3.2 内存与交换分区OOM的前兆信号内存问题最危险的是OOMOut Of Memory。Linux在内存不足时会触发OOM Killer随机杀掉一个进程来释放内存。被杀的往往是占用内存最大的进程可能是你的数据库或应用服务。监控内存除了free -h还要看/proc/meminfo里的Committed_AS和CommitLimit。如果Committed_AS接近CommitLimit说明系统已经过度承诺内存随时可能触发OOM。grep -E CommitLimit|Committed_AS /proc/meminfo交换分区swap的使用情况也值得关注。vmstat 1输出的si和so列分别表示换入和换出速率。如果这两个值持续非零说明物理内存不够系统在频繁换页性能会急剧下降。vmstat 1 5 # si/so 持续大于0说明内存压力大3.3 磁盘IO最容易被忽视的瓶颈磁盘IO问题往往表现为系统很卡但CPU不高。iostat -x 1是排查IO问题的利器重点关注%util和await两列。%util接近100%说明磁盘饱和await是平均等待时间毫秒机械硬盘超过20ms、SSD超过5ms就值得警惕了。iostat -x 1 3 # 关注 %util 和 await以及 r/s、w/s 判断是读多还是写多iotop能按进程显示IO占用但需要root权限且内核开启CONFIG_TASK_IO_ACCOUNTING。如果iotop不可用可以用pidstat -d 1替代它按进程统计读写速率。pidstat -d 1 5 # 输出每个进程的 kB_rd/s 和 kB_wr/s3.4 网络流量带宽跑满了吗网络监控用sar -n DEV 1或iftop。sar是sysstat包的一部分能看历史数据适合事后分析。iftop实时显示各连接的带宽占用适合定位谁在偷跑流量。sar -n DEV 1 5 # 关注 rxkB/s 和 txkB/s对比网卡标称带宽如果发现带宽跑满下一步是用ss -tunp看具体是哪些连接在传输。ss比netstat快得多在连接数多的时候优势明显。ss -tunp | head -30 # -t TCP, -u UDP, -n 不解析服务名, -p 显示进程提示建立基线的方法很简单——在系统正常运行时每隔一段时间采集一次上述指标记录在表格里。坚持一两周你就能看出哪些波动是正常的哪些是异常的。4. 故障定位实战从现象到根因的排查链路前面讲的是看什么这一章讲怎么想。故障排查最忌讳东一榔头西一棒子必须有清晰的排查链路。我通常按照现象确认→范围缩小→根因定位→验证修复四步走。4.1 服务不可用先确认是进程问题还是网络问题假设用户反馈网站打不开。第一步不是重启服务而是确认服务进程是否还在。systemctl status nginx # 或者用 ps 检查 ps aux | grep nginx | grep -v grep如果进程在但服务不可用下一步检查端口监听状态ss -tlnp | grep :80 # 确认是否有进程监听80端口如果端口没监听说明服务启动失败或配置有问题。这时候看日志journalctl -u nginx --since 10 minutes ago # 或者看应用自己的日志文件 tail -100 /var/log/nginx/error.log如果端口在监听但外部访问不了问题可能出在防火墙或安全组。检查本机防火墙规则iptables -L -n # 或者 firewalld firewall-cmd --list-all这里有个经验云服务器的安全组规则和本机防火墙是两层独立的过滤任何一层没放行都会导致访问失败。排查时两层都要看。4.2 系统响应慢用排除法锁定资源瓶颈系统变慢的原因无非四种CPU忙、内存不足、磁盘IO高、网络拥塞。用vmstat 1可以快速排除vmstat 1 5 # r 列等待运行的进程数持续大于CPU核数说明CPU不够 # si/so换页速率非零说明内存不足 # waIO等待高说明磁盘慢根据vmstat的输出基本能判断瓶颈方向。如果是CPU问题用top找占用最高的进程如果是内存问题用ps aux --sort-%mem | head找内存大户如果是IO问题用iostat -x和pidstat -d定位具体磁盘和进程。ps aux --sort-%mem | head -10 ps aux --sort-%cpu | head -104.3 磁盘空间告急df和du不一致怎么办df -h显示磁盘满了但du -sh /*统计出来却小很多。这是运维中最经典的幽灵空间问题。原因是某个大文件被删除了但仍有进程持有它的文件句柄内核不会释放这部分空间。定位方法lsof | grep deleted | head -20 # 找到持有已删除文件的进程PID解决办法是重启该进程或者用 /proc/PID/fd/FD清空文件内容不推荐可能导致进程异常。最稳妥的还是重启进程。另一个常见原因是inode耗尽。df -i查看inode使用率如果100%了即使空间还有剩余也无法创建新文件。这种情况通常是大量小文件导致的比如缓存目录、邮件队列、session文件。清理这些目录即可。df -i # 找到inode使用率高的挂载点然后统计该目录下文件数量 find /var/spool -type f | wc -l4.4 进程杀不掉僵尸进程与不可中断睡眠kill -9都杀不掉的进程通常处于D状态不可中断睡眠一般是在等待IO完成。这时候看进程的wchan内核等待通道ps -eo pid,stat,wchan,cmd | grep D cat /proc/PID/stack如果确认是IO问题需要先解决底层存储的故障进程才会恢复。强行杀D状态进程是无效的因为它不响应信号。僵尸进程Z状态则是另一种情况。僵尸进程本身不占资源但会占用进程表项。如果大量僵尸进程堆积说明父进程没有正确回收子进程。解决办法是找到父进程并重启它。ps -eo pid,ppid,stat,cmd | awk $3 ~ /Z/ # 找到僵尸进程的PPID然后处理父进程4.5 网络连接异常从socket状态入手ss -s能快速汇总当前socket状态如果TIME_WAIT数量异常大说明短连接过多可能需要调整内核参数或改用长连接。ss -s # 输出各状态连接数统计TIME_WAIT过多的调优参数# 查看当前值 sysctl net.ipv4.tcp_tw_reuse sysctl net.ipv4.tcp_max_tw_buckets # 临时调整 sysctl -w net.ipv4.tcp_tw_reuse1但要注意tcp_tw_reuse只对客户端有效服务端大量TIME_WAIT应该从应用层优化比如使用连接池。如果连接被拒绝Connection refused说明目标端口没有监听如果是超时Connection timed out说明网络不通或被防火墙拦截。用traceroute或mtr可以看链路在哪一跳断了。mtr -r -c 10 192.168.1.100 # 报告模式发送10个包显示每跳丢包率5. 日志分析与事后复盘让每一次故障都变成经验故障解决后如果不做复盘下次遇到类似问题还是要从头查起。日志是最宝贵的线索来源但前提是你会用工具高效地检索和分析。5.1 journalctlsystemd体系的日志中枢现代Linux发行版基本都用systemd管理服务journalctl就是查看日志的统一入口。常用组合# 查看指定服务的日志 journalctl -u nginx --since today # 按时间范围过滤 journalctl --since 2024-01-01 10:00:00 --until 2024-01-01 11:00:00 # 只看错误级别 journalctl -p err -b # 实时跟踪 journalctl -f -u nginx-b参数表示只看本次启动以来的日志排查重启后的问题特别有用。-p按优先级过滤err及以上级别才会显示。如果日志量很大可以配合grep做二次过滤journalctl -u nginx --since 1 hour ago | grep -i error\|fail\|timeout5.2 传统日志文件tail、grep、awk的组合拳不是所有服务都走journald很多应用还是写自己的日志文件。tail -f实时跟踪是最基本的操作但面对大文件直接grep可能很慢。这时候可以用awk按时间范围过滤awk /2024-01-01 10:00/,/2024-01-01 11:00/ /var/log/app.log统计错误出现次数grep -c ERROR /var/log/app.log按错误类型分组统计grep ERROR /var/log/app.log | awk {print $5} | sort | uniq -c | sort -rn | head这个组合能快速告诉你哪类错误最多优先解决高频问题。5.3 日志轮转与磁盘保护日志写满磁盘是新手常踩的坑。logrotate是标准的日志轮转工具配置文件在/etc/logrotate.d/下。检查某个服务的轮转配置cat /etc/logrotate.d/nginx关键参数daily每天轮转、rotate 7保留7份、compress压缩旧日志、size 100M超过100M就轮转。如果日志增长太快可以调小size或增加轮转频率。手动触发轮转测试logrotate -d /etc/logrotate.d/nginx # -d 调试模式只显示会做什么不实际执行注意修改logrotate配置后最好用-d先验证一遍确认无误再实际执行。我曾经因为配置里少了个空格导致日志被轮转后没有创建新文件服务直接写不进去了。6. 几条容易被忽略但关键时刻能救命的命令前面讲的都是系统性的排查方法最后分享几条偏方级别的命令平时用不到但特定场景下能省很多时间。6.1 用strace跟踪系统调用当某个进程行为异常但日志里没有有用信息时strace能直接看它调用了哪些系统调用、卡在哪一步。strace -p PID -f -e tracenetwork # 跟踪指定进程的网络相关系统调用-f表示跟踪子进程-e trace可以过滤特定类型的调用。比如排查连接超时就跟踪network排查文件问题就跟踪file。但要注意strace会显著降低进程性能生产环境慎用最好只在测试环境或问题复现时短时间使用。6.2 用lsof找回被删除的文件前面提到lsof | grep deleted能找到被删除但未释放的文件。如果这个文件很重要还能通过/proc/PID/fd/FD路径把它复制出来cp /proc/1234/fd/5 /tmp/recovered_file前提是文件句柄还在进程还没重启。这个技巧在误删配置文件时特别有用。6.3 用dmesg看内核消息有些问题日志里看不到但内核已经记录了。比如OOM Killer杀进程、磁盘IO错误、网卡丢包都会在dmesg里留下痕迹。dmesg -T | tail -50 # -T 显示可读时间戳如果看到Out of memory: Killed process说明发生了OOM看到I/O error说明磁盘有硬件问题。这些信息对定位根因至关重要。6.4 用nc和curl做快速连通性测试nc -zv host port测试TCP端口连通性curl -I测试HTTP服务可用性curl -w输出详细的请求耗时分解curl -o /dev/null -s -w DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n http://example.com这个输出能帮你判断慢在DNS解析、TCP连接还是服务端处理。如果time_namelookup很长说明DNS有问题如果time_connect很长说明网络延迟高如果time_starttransfer很长说明服务端处理慢。7. 把命令变成肌肉记忆我的日常练习方法说了这么多命令最后聊聊怎么真正掌握它们。我的经验是不要试图一次记住所有参数而是围绕场景反复练习。比如这周专门练磁盘排查遇到任何磁盘相关问题都强迫自己用df、du、lsof、iostat这套组合去分析练到不用查文档就能敲出来为止。另一个方法是给自己出题。比如故意用dd命令把某个分区写满然后练习定位和清理或者用stress工具制造CPU和内存压力练习用top、vmstat、pidstat定位瓶颈。这种自导自演的故障演练比看十篇文章都管用。还有一点很重要养成记录的习惯。每次排查完一个故障把现象、排查过程、根因、解决方案记下来。积累多了你会发现很多问题其实是同一类排查思路可以复用。我自己的笔记里就有一个故障模式库按现象分类比如服务无响应、磁盘满、CPU高、网络慢每个模式下列出可能的原因和对应的排查命令。遇到新问题先查库能省很多时间。提示如果你在云环境里练习注意不要在生产实例上做破坏性操作。可以开一台按量付费的测试机用完就释放成本很低。Linux命令行的学习曲线确实有点陡但一旦跨过那个坎你会发现它是最自由、最高效的操作方式。图形界面能做的事命令行都能做图形界面做不了的事命令行也能做。而且命令行的输出是文本可以管道、可以重定向、可以脚本化这是图形界面永远比不了的。希望这篇内容能帮你建立起自己的排查思路下次遇到问题时不再慌张而是有条不紊地一步步逼近根因。