1. “基本工具”四个字是新人最容易看轻的部分提到Linux基本工具很多人的第一反应是“不就是ls、cd、cat那一套吗”。我这些年跟服务器打交道下来越来越觉得“基本”这个词被严重低估了。线上出问题时能救命的反而不是某个花哨的新框架而是这几个朴素命令的组合。我甚至见过一些人把参数背得滚瓜烂熟真到现场却不知道从哪一条开始敲这才是最尴尬的。所谓基本工具其实指的是那些在绝大多数Linux发行版里默认存在、参数稳定、行为成熟的老牌命令行程序。它们看起来各自独立但真正的工作方式从来不是单打独斗而是像螺丝刀和扳手一样配合使用。理解这一点才能理解为什么老手总说“工具不重要组合才重要”。1.1 一次线上告警的排查顺序能说明很多东西某天凌晨我负责的一个模拟项目X突然收到报警服务响应时间从平时的50毫秒涨到了三秒以上。登录服务器后我没有急着打开日志文件翻到底而是先敲了三条命令top、ps aux、free -h。这不是什么高深的操作但顺序对了信息密度完全不同。top让我看到整体负载和CPU使用率ps aux --sort-%cpu帮我把CPU占用最高的进程拎出来free -h验证了内存并没有耗尽。随后我用vmstat 1 5看了连续五秒的CPU队列和上下文切换才定位到是应用进程在做高频垃圾回收。整个过程不到十分钟全部用的都是“基本工具”。事后我想过如果当时我直接去翻业务日志很可能被海量信息淹没。基础命令的价值恰恰在于它们能快速帮你建立“当前机器到底处于什么状态”的直觉。没有这个直觉任何高级工具都像没有地基的楼。1.2 所谓“会用”其实是“知道什么时候该用哪一把”很多教程会把工具一个个列出来然后给一堆参数的表格。这样做当然不算错但容易让新手产生一种错觉只要把参数背下来就算会了。实际上真正的会用指的是知道“什么时候该想到它”。比如df -h看的是文件系统剩余空间df -i看的是inode剩余数量。租户上传了大量小文件导致inode用尽时df -h依然显示空间充足但业务已经无法创建任何新文件。如果脑子里没有“还有inode这回事”排障就会卡在“明明空间够但写不进文件”这种诡异现象上。所以我写这篇东西不太想按命令字典的方式讲而更想按“遇到什么情况用哪几条命令为什么这样组合”的思路来组织。这也是这篇内容的真正价值所在。2. 文本处理三件套grep、sed、awk怎么配合才顺手日志、配置、脚本、进程列表Linux下几乎所有东西最终都会落到文本上。所以文本处理能力基本决定了你在服务器上的工作效率。grep、sed、awk这三件套就是其中最核心的底牌。这三兄弟各有分工grep负责筛sed负责改awk负责算。分开用都能干点事组合起来才真正顺手。2.1 grep先要学会的是“怎么少看无用信息”grep最常见的用途是过滤出关键行比如从日志里找某个关键字。但很多人只用了最基础的grep error app.log这样出来的结果往往又长又杂反而更难发现问题。我平时更常用这几组参数组合grep -E ERROR|Exception app.log用正则一次匹配多个关键字避免二次筛选。grep -i忽略大小写尤其适合排查error和Error混用的日志。grep -v heartbeat app.log反向过滤把心跳包这种正常噪音去掉。grep -B5 -A10 严重错误 app.log把匹配行之前5行和之后10行一起带出来直接看到异常发生的上下文。grep -rl 关键字 /var/log/只列出包含关键字的文件名适合在多个日志目录里定位问题源。grep -c 关键字 app.log只看匹配行数适合快速判断异常频率是否在涨。举个实际例子。某次我排查接口偶发超时直接用grep timeout /var/log/app/*.log | grep -v health先筛出所有非健康检查的超时记录再通过grep -c按小时对比数量很快就确认了超时集中在某个调度任务运行的时间段。整个过程没有写任何脚本就是几条grep命令的组合。2.2 sed和awk一个负责改一个负责算sed最常被我用来做三类事情行内替换、删除指定范围、打印指定行。替换并预览sed s/原串/新串/g old.txt不加-i参数只是预览安全。确认无误后可用sed -i.bak s/原串/新串/g old.txt-i.bak会在原地修改前自动生成备份文件。删除连续区间sed 100,200d app.log只输出删掉100到200行之后的内容适合截掉日志里已知的噪音段。打印指定行sed -n 20,30p app.conf直接看配置文件某几行的内容不用打开整个文件。按行号或正则取最后一匹配sed -n /最后一次标记/,/第一次标记/p file这种区间模式在提取特定片段时非常有用。awk的核心优势是处理“按列组织的文本”。默认按空格或Tab分割字段$1、$2分别代表第一列、第二列$0代表整行。我常听的思路是“一旦你发现自己在用excel处理服务器文本那这活就该交给awk”。典型场景统计nginx访问日志里每个状态码的数量。awk {print $9} access.log | sort | uniq -c | sort -rn这条命令先取出第九列状态码然后排序去重统计最后按数量降序排列。加一行过滤能看得更细比如统计真实用户请求而非监控探针awk $9 ! 200 {print $9, $7} access.log | sort | uniq -c | sort -rn | head -20还有更进阶的按IP统计请求次数并过滤超过阈值的awk {count[$1]} END {for (ip in count) if (count[ip] 500) print ip, count[ip]} access.log2.3 三段式组合日志分析的常见流水线大多数日志分析任务都可以套一个三段式组合grep先过滤出目标子集sed把不需要的字段或碎片清掉awk对结果做统计或抽取。有一次我处理一个支付回调日志的乱序问题。日志里每一行都有时间戳、订单号和回调状态问题表现为订单完成时间超过预期。我的分析命令是grep 回调完成 pay.log | sed s/\[.*\]// | awk {print $3, $5} | sort | uniq -c | sort -k1 -ngrep先把所有回调完成行筛出来sed把前面带括号的前缀信息清掉awk把订单状态和时间字段单独提取最后按出现次数排序。这样一跑哪些订单在固定周期内反复回调就一目了然了。新手常犯的一个错误是试图在一个命令里同时完成所有事情结果正则越写越复杂稍微改一下日志格式就崩了。我的建议是故意拆成多步每一步的输出都能肉眼检查定位问题时也方便确认到底是哪一步出了问题。3. 系统状态排查top、ps、free、vmstat一起看才有意义服务器卡了、慢了、负载高了这是运维场景里最常见的三类告警。很多人一上来就敲top盯着屏幕上的CPU百分比发呆但top给的是实时快照光看那一屏数据是不够的。系统状态排查需要组合拳top、ps、free、vmstat各管一段一起看才能拼出完整画面。3.1 top看起来简单关键在辨别几个数字背后的含义top打开后的第一行是平均负载load average三个数字分别代表1分钟、5分钟、15分钟的平均值。很多人看到负载大于1就紧张但负载高低必须结合CPU核数判断。四核机器负载到4才算满载负载到8则明显超载但如果是十六核机器负载4根本不算事。top里第二行需要关注的是us和sy两个指标us是用户态CPU占用sy是内核态CPU占用。sy长期偏高通常暗示系统调用频繁、锁竞争严重或网络中断过多这时候光看哪个进程CPU高还不够要配合vmstat看上下文切换。交互操作也得熟悉按P按CPU排序按M按内存排序按1查看每个CPU核心的分别使用率按c展开完整命令行。很多新人不知道按c之后能看到进程的完整启动参数这在排查定时任务脚本为什么反复重启时特别重要。3.2 ps和free定位“谁在吃资源”的基本功ps aux是获取进程全貌的经典用法但输出列太多直接看容易眼花。我习惯先用ps aux --sort-%cpu | head -15看CPU占用最高的进程再用ps aux --sort-%mem | head -15看内存占用最高的进程。两次排序就能快速锁定可疑对象。ps里有几个状态码要认识R表示运行中S表示可中断睡眠D表示不可中断睡眠通常是等IOZ表示僵尸进程。如果D状态进程大量堆积说明磁盘或者网络IO有堵塞如果Z状态在增长就看它的父进程是否还活着父进程没退出僵尸就清不掉。free -h的关切成在于理解buff/cache和available的区别。很多人看到used占比高就以为内存不足其实Linux会把空闲内存尽量拿去做文件缓存这部分在压力大时能被自动回收。判断内存是否紧张应该优先看available它才是“还能直接分给应用程序的内存”的近似值。3.3 vmstat用一个命令把整台机器的节奏看明白vmstat 1 5每秒采样一次连续采五次输出的信息密度相当高。我最关注的是这些字段r正在运行的进程数。持续大于CPU核数说明CPU资源吃紧。b不可中断睡眠的进程数偏高通常与IO阻塞有关。si、so从磁盘换入、换出到磁盘的内存量。只要这两个值长期为非零内存就是真的不够用了。us、sy、id、wa用户态、系统态、空闲、等待IO的时间占比。cs上下文切换次数。偏高意味着系统在频繁切换进程或线程往往伴随锁竞争。有一次我看top里CPU使用率只有30%但业务响应很慢于是vmstat 1 5一看cs字段高得离谱sy也明显偏高。进一步检查后发现是某个服务用频繁轮询代替了阻塞等待改掉那个逻辑之后负载立刻恢复正常。如果只看top的CPU百分比我可能还要再折腾半天才能反应过来。4. 磁盘体检别等写不进去才想起来磁盘问题最坑的地方在于“平时看不出来出事就是大事”。文件系统写满、inode耗尽、删了文件空间却不释放这些都是我在生产环境里真实踩过的坑。磁盘工具本身不复杂难的是养成主动检查的习惯以及知道每个命令对应什么现象。4.1 df、du、inode三分钟看磁盘健康度判断磁盘是否健康我一般按这个顺序看df -h看挂载点使用比例。使用率到80%就该留意超过90%基本要准备清理或扩容了。df -i看inode使用率。这个命令很多新人压根没用过但小文件堆积导致inode吃紧的问题在大数据存储目录、消息队列临时目录里特别常见。du -h --max-depth1 /var | sort -hr | head -10直接列出某个目录下各子目录占用的空间大小从大到小排序一眼就能看出空间被谁吃掉了。du有个实用技巧不要对根目录直接跑全量du -sh /那样要很久。先du --max-depth1 -h /看一层再进入二级目录逐层下钻效率高得多。我还见过一种情况df -h显示目录空间充足但应用一直报“No space left on device”。排查到最后才发现是/tmp挂载了一个很小的独立分区应用把临时文件全写到那里去了。所以看磁盘别只看根分区df -h列出的每一个挂载点都得扫一遍。4.2 处理“删了文件但空间没少”的常见情况删了文件但df -h空间没变这是咨询频率最高的问题之一。原因通常是还有进程持有该文件的句柄文件虽然在目录里看不见了但内核还没真正释放磁盘块。排查命令是lsof | grep deleted输出里会列出那些已被删除但仍在被进程占用的文件。看到结果后需要评估持有该句柄的进程是否可以安全重启或重载。进程重启后空间才会真正释放。这里有个教训如果只是想临时腾空间千万别在没确认句柄占用前就反复rm同一个文件。先找句柄、再决定是重启进程还是清空文件内容比如 /path/to/file才是稳妥的做法。4.3 挂载和fstab出问题最容易在重启后磁盘挂载本身不复杂lsblk能列出块设备树mount -a能按/etc/fstab重新挂载所有条目。但/etc/fstab写错导致的启动失败是我见过最多的高危事故之一。主要坑点有三个使用设备名如/dev/sdb1而不是UUID。设备名在系统启动顺序变化后可能变成/dev/sdc1直接导致挂载失败。建议用blkid查UUID后写入/etc/fstab。文件系统类型写错。比如实际是xfs写成ext4启动时大概率挂载失败。加了noauto却期待它自动挂载或者漏了nofail导致启动卡死。普通数据盘建议加nofail至少系统能正常进入给你修复的余地。每次修改完/etc/fstab可以先mount -a试一下再看是否报错。不要直接重启服务器否则可能直接进不去系统。5. 网络排查从能ping通到能讲清楚卡在哪网络类问题在Linux环境里占比不低。很多人遇到“访问不了”就是一顿ping能通就认为网络没问题不能通就束手无策。真正的基本功是从头到尾把链路拆开客户端发起请求、DNS解析、TCP连接、数据传输、服务端响应每一段都有对应的工具和验证方法。5.1 ping、traceroute、ss摸清链路基本盘ping验证的是最基本的网络连通性和延迟但它的结果受防火墙、路由策略影响很大。有些节点禁ICMPping不通不代表业务不通所以ping结果要说“ICMP不可达”不能直接下结论说网络断了。traceroute -n能看到数据包经过的每一跳网关以及每一跳的延迟。延迟在某一个跳突然飙升通常说明跨运营商链路或专线出口在那里出现了拥堵。但要注意中间路由器的延迟不代表端到端质量有些路由器对ICMP包的处理优先级很低显示几百毫秒的延迟可能只是它懒得回你。真正需要重点掌握的是ss。它是netstat的替代者输出更友好。常见用法ss -lntp查看所有监听中的TCP端口及对应进程排查“端口被谁占用”的首选。ss -s看整机TCP连接状态的汇总适合快速了解有多少连接在ESTABLISHED、TIME_WAIT等状态。ss state time-wait count按状态统计连接数比如ss state time-wait | wc -l看TIME_WAIT连接总量。ss -lntp配合grep能快速定位端口归属进程。有一次我发现503端口被某个进程占用但业务预期它应该监听在505端口一查ss -lnpt | grep 503原来是一个旧版本服务没完全退出。这种问题没有ss排查起来非常痛苦。5.2 curl、dig把“慢”和“不通”量化排查“网页打开慢”时我习惯用curl的详细计时来量化慢在哪一步curl -o /dev/null -s -w DNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nTLS握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\n https://example.com-o /dev/null丢弃响应体-s静默模式-w自定义输出。如果DNS解析时间长问题在解析链路如果TCP连接时间长考虑网络链路和防火墙如果TLS握手慢可能是证书链或加密套件协商问题如果首字节慢但前面都快基本可以确定是服务端处理慢。DNS方面dig short example.com能直接拿到解析结果dig example.com CNAME查看别名链。排查域名解析异常时先用dig 127.0.0.1测试本地DNS服务器是否正常再dig 8.8.8.8公共DNS对比可以快速判断是上游解析问题还是本地缓存问题。当然公共DNS地址只用于对比实验生产环境的解析策略以公司规范为准。5.3 tcpdump兜底工具建议提前熟悉前面的工具都解决不了问题时就该上tcpdump了。它的作用是直接抓取网卡数据包看到最原始的交互过程。基本用法tcpdump -nn -i any port 80 -c 100-nn不解析主机名和端口名-i any抓所有网卡port 80按端口过滤-c 100抓100个包后自动停止。抓完用-w file.pcap保存然后用tcpdump -r file.pcap或相关工具分析。有一次排查“客户端报连接被重置”我抓包发现服务端先回了RST包才意识到是服务端主动断开连接和网络链路没关系。顺着这个线索查下去发现是服务端的空闲连接超时配置太短。如果当时只依赖应用日志这个问题很难定位到底层原因。这里有个建议别等到故障时刻才第一次用tcpdump。提前在测试环境抓几次正常流量熟悉输出格式和常见标志位真正排障时才能不慌。6. 把零散命令沉淀成自己的工具箱前面几章讲的是“遇到问题用什么命令”但工具用得顺不顺还取决于日常有没有做沉淀。同样一条命令老手敲得快不是因为他手速快而是他把常用组合封装成了别名、函数和脚本把低频操作焊进了肌肉记忆。6.1 alias、函数、脚本把常用组合变成一键我自己的~/.bashrc里保留了几条高频别名基本都是把多步组合固化下来的alias grepgrep --colorauto alias llls -lh alias topcpups aux --sort-%cpu | head -15 alias topmemps aux --sort-%mem | head -15 alias dfhdf -h | grep -v tmpfs alias portsss -lntp这些别名看起来简单日常使用频率却非常高。比如topcpu把“查CPU占用最高进程”从三条命令缩成一个词每次排查问题都能少敲几个字符。更进一步是写几行函数。比如快速查看某个服务的端口、状态和最近日志svccheck() { echo 端口 ss -lntp 2/dev/null | grep -w $1 || echo 未找到端口 $1 echo 进程 ps aux | grep -w $1 | grep -v grep echo 日志 journalctl -u $1 --no-pager -n 20 2/dev/null || tail -n 20 /var/log/$1/log }这类函数不用写得多复杂关键是能省掉每次重复输入的麻烦。把常用组合脚本化之后排障速度和准确率都会有明显提升。6.2 历史命令的习惯CtrlR帮你找回灵感很多人不知道服务器上的history其实是一座金矿。当你回忆不起来上个月是怎么处理类似问题的时候CtrlR反向搜索历史命令能直接帮你想起来。养成在关键操作后做记录的习惯历史命令就是你的个人排障手册。我建议把HISTSIZE和HISTFILESIZE调大一些默认值太小很多有价值的命令会被挤掉export HISTSIZE10000 export HISTFILESIZE20000另外推荐用history 50查看最近五十条命令在写脚本需要复制某条长命令时会非常方便。6.3 安全意识命令越基础失误代价越高最后想提醒的是基础工具因为天天用反而最容易因为肌肉记忆造成事故。rm -rf就不必多说了改文件权限、管道命令、dd写盘都需要格外谨慎。我自己的几个铁律凡是删除操作先ls确认路径再删绝不直接敲rm -rf拼接变量。凡是批量替换文件内容先用sed的预览模式检查替换结果再决定是否加-i。凡是要在线上机器跑可能影响业务的命令如dd、mkfs、reboot先确认当前目录再确认设备名最后确认命令语法。宁可多花几十秒也要避免不可逆的操作风险。对配置文件的改动永远先备份。一条cp命令的成本远低于改坏了再恢复的代价。有一次我想清空一个日志文件下意识敲了rm突然想起这个文件的路径是符号链接rm会把整个链接删除而不是清空内容。幸好当时停住了。这种细节没什么高级技巧就是靠一遍遍提醒自己养成习惯。Linux基本工具真正用得好的人往往赢在日常这些不起眼的细节里。命令本身从不是难点难的是对每个命令背后的行为和边界有足够敬畏。希望这篇内容能给你一些参考哪怕只帮你少踩一个坑也值得。