1. 基层操作文件与文本处理是后端每天的体力活后端开发跟Linux打交道频率最高的其实不是那些花哨的性能调优命令而是最基础的文件查看、日志追踪和文本检索。很多人觉得这些太简单不值得专门总结但实际上线上问题排查的黄金十分钟往往就耗在“找不到日志在哪”“不会快速过滤关键信息”这些看似基础的事情上。1.1 查看文件别只会用cat组合拳才是常态承接上文文件查看虽然基础但不同场景下工具选择完全不同。cat适合查看小文件全文超过几百行的输出直接刷屏根本没法看。更实用的做法是# 查看文件前N行默认10行 head -n 50 app.log # 查看文件末尾N行排查崩溃原因基本靠这个 tail -n 100 app.log # 实时跟踪日志输出服务调试时挂一个终端专门跑这个 tail -f app.logtail -f是后端排查问题时使用频率最高的命令之一。服务报错了先打开日志文件所在的目录执行tail -f然后复现问题日志会一屏一屏地滚动问题原因基本能看出个大概。如果日志量特别大还可以加上grep过滤tail -f app.log | grep -E ERROR|Exception这条命令相当于给日志装了个筛子只把错误级别的信息漏出来不至于被海量正常日志淹没。实际工作中我还习惯搭配--pid参数先pgrep -f java找到进程号再用tail -f --pid1234 app.log这样进程一退出tail 命令也会自动结束不需要手动 CtrlC在自动化脚本里尤其好用。1.2 文本检索grep的进阶用法能救命后端查日志绕不开grep但很多人只会最基础的grep 关键字 文件效率其实很低。分享几个我实测下来非常高频的用法# 递归搜索某个目录下所有文件线上日志按天切割时特别有用 grep -r 订单号20241228 /data/logs/ # 同时搜索多个关键词用 -E 开启扩展正则 grep -E NullPointerException|OutOfMemoryError app.log # 显示匹配行的前后几行看异常堆栈时必需 grep -n -A 5 -B 2 Exception app.log # 统计某个关键词出现的次数 grep -c ERROR app.log-A和-B参数是看 Java/Python 异常堆栈的利器。异常栈通常不是一行而是十几行连续的堆栈信息只看匹配行根本定位不到业务代码。加上-A 10把异常后面的上下文打出来才能看到具体是哪段业务逻辑出的问题。注意grep 默认是区分大小写的查日志时如果关键字大小写不确定记得加-i参数忽略大小写否则容易漏掉关键信息。1.3 文件查找别再一条条 ls 翻目录了项目代码、配置文件分布在多个目录靠ls一层层进去翻显然太低效。find命令应该成为肌肉记忆# 按文件名查找支持通配符 find /etc -name *.conf # 按时间查找24小时内修改过的文件 find /data -mtime -1 # 按大小查找超过500M的大文件排查磁盘满时第一步就查这个 find / -size 500M我排查磁盘报警时习惯先执行df -h看整体占用再执行find /data -size 1G -exec ls -lh {} \;把大文件逐个揪出来。这里-exec的作用是找到的结果再执行一次后面的命令最终输出文件大小比光秃秃的路径直观得多。2. 进程与服务管理线上服务出问题时的第一道防线文件操作解决的是“看什么”的问题进程管理解决的是“谁在跑、跑没跑、挂了没有”的问题。后端开发日常部署服务、重启应用、排查僵死进程本质都是在跟进程打交道。2.1 查看进程ps命令的参数组合要记牢先看最基础的ps# 查看所有进程包含完整命令行参数 ps -ef # 查找某个服务的进程号 ps -ef | grep javaps -ef输出的第二列是 PID第八列是启动命令。实际工作中我更喜欢用ps -aux因为能看到 CPU 和内存占用率快速判断哪个进程在“偷吃”资源。配合sort可以按 CPU 使用率排序ps -aux --sort-%cpu | head -n 10这个命令一执行CPU 占用最高的前十个进程立刻现形。之前遇到一次线上 CPU 飙升到 100% 的情况就是用这条命令在几秒内定位到是一个异常的任务线程在疯狂空转而不是盲目地去重启整个服务。2.2 管理进程kill的优雅与强制搞清楚进程号之后就要进行干预。kill命令有几个信号需要区分清楚# 优雅停止让进程处理完手头的事情再退出 kill -15 PID # 强制杀死进程无响应时兜底使用 kill -9 PID # 按进程名批量结束慎用会把所有同名进程全部杀掉 pkill -f service-akill -15是默认信号相当于给进程发了一个“该下班了”的通知进程收到后可以执行清理逻辑。但有时候进程卡死了-15根本没反应这时候才用-9强制终止相当于直接拔电源。注意kill -9是最后的手段不是第一选择。直接拔电源可能导致数据未落盘、文件损坏。我先用-15等 10 秒没反应再升级为-9。2.3 端口与连接排查lsof和netstat后端服务启动失败最常见的原因就是端口被占用。排查端口占用有一套固定流程# 查看某个端口被哪个进程占用 lsof -i:8080 # 不带 lsof 的替代方案通用性更强 netstat -tlnp | grep 8080lsof -i:8080输出里PID 列直接告诉你谁占着端口。拿到 PID 后可以进一步确认进程信息ps -p PID -f这套组合拳我几乎每天都要用。部署新服务时如果报“端口已经被占用”先lsof -i:8080看是不是旧服务的残留进程再决定是kill旧进程还是换个端口而不是一头雾水地反复重启。2.4 后台运行nohup与日志重定向后端开发经常要临时跑一个服务但不能一直挂着终端窗口。规范的启动方式是nohup java -jar app.jar --spring.profiles.activeprod app.log 21 这条命令里有两个关键点nohup让进程忽略终端挂断信号终端关了进程依然在跑21把标准错误重定向到标准输出都写进同一个日志文件否则错误信息会丢在终端里不少新人栽在21这个细节上只写了 app.log结果进程的各种报错直接打印在屏幕上关掉终端后错误信息就彻底丢了排查问题完全没有依据。启动后建议立刻确认一下进程真的活着ps -ef | grep app.jar tail -f app.log3. 资源监控与系统体检CPU、内存、磁盘、负载的四维观察进程管理解决的是“某个具体服务”的问题但线上故障经常是整台机器层面的比如 CPU 被打满、内存耗尽、磁盘写满、系统负载过高。这时候需要把视角从进程拉高到整个系统。3.1 整体负载top命令的深度解读top命令是系统体检的起点top进入交互界面后重点看三块信息第一行的load average有三个数字分别代表 1 分钟、5 分钟、15 分钟的平均负载。数字除以 CPU 核心数超过 0.7 就该警惕了第三行的%Cpu(s)重点关注us用户态占用和waI/O 等待wa高说明磁盘 I/O 有瓶颈进程列表里按P键可以按 CPU 排序按M键按内存排序top默认 3 秒刷新一次如果想只看某个进程的资源占用可以在交互界面按u键输入进程号或者直接用top -p PID3.2 内存与磁盘free和df的常规检查内存和磁盘是后端服务最容易踩坑的资源瓶颈。# 查看内存使用情况 free -h # 查看磁盘空间 df -h # 查看当前目录下各子目录占用大小 du -sh *free -h输出里有个关键概念available才是真正可用的内存而不是free。因为 Linux 会把空闲内存用作文件缓存buff/cache这部分在应用需要时可以释放所以别看到free只有几百兆就慌要判断available还剩多少。磁盘这块df -h查看的是文件系统级别的占用du -sh *能定位到具体是哪个目录在疯狂吃磁盘。清理日志文件时我习惯先du -sh * | sort -rh按容量排个序再决定先清理谁。3.3 I/O 瓶颈iostat与iotopCPU 和内存还好排查I/O 问题往往藏得比较深。应用响应慢但 CPU 和内存看着都正常十有八九是磁盘 I/O 扛不住了。# 查看磁盘读写速率 iostat -x 1 3 # 动态查看哪些进程在大量读写磁盘 iotop -oiostat -x的输出里重点看%util这一列如果接近 100%说明磁盘已经满负荷运转了。iotop -o能看到具体是哪个进程在疯狂读写磁盘场景一般是日志写得太频繁或者某个任务在批量刷数据。注意iostat 和 iotop 默认可能没安装需要先执行yum install sysstatCentOS或apt install sysstatUbuntu。很多生产环境资料都提到过问题发生时临时装工具可能比等工具装完还急人所以尽量在系统初始化时就把这些排查工具装好。4. 网络排查与文件传输后端联调和部署的必修课后端开发离不开网络操作接口调不通要排查连通性服务器之间要传文件跟数据库建连超时也要查网络。这块的命令看起来不多但用好了能省大量沟通成本。4.1 连通性测试ping、telnet与nc排查网络连通性问题很多人只知道ping# 测试网络通不通 ping -c 4 192.168.1.10 # 测试某个 TCP 端口是否能连通 telnet 192.168.1.10 3306 # nc 是 telnet 的现代替代品 nc -vz 192.168.1.10 3306ping测的是 ICMP 协议只要机器活着就会响应但能ping通不代表端口能通。数据库连接超时、接口调不通十有八九是端口被防火墙挡住了。用telnet 目标IP 目标端口如果能连上会显示连接成功如果卡住或报错就是端口不通。nc -vz是 telnet 的替代品功能类似还支持批量扫描端口范围nc -vz 192.168.1.10 8000-9000这个命令一次可以扫 1000 个端口排查服务端口开放情况时非常好用。4.2 路由与抓包traceroute与tcpdump跨网络调用出问题时光靠 ping 和 telnet 还不够需要看数据包走到哪一步被丢掉了# 追踪路由路径看数据包经过哪些跳点 traceroute -n 192.168.1.10 # 抓取某个端口上的流量包 tcpdump -i eth0 port 8080 -w /tmp/capture.pcaptraceroute能看出网络在哪一跳延迟飙升比如多次调用都卡在某一个中间 IP那问题大概率出在这台跳板机上。tcpdump更底层能直接看到数据包的内容和方向排查“请求发出去了但服务端没收到”这类问题时能在服务端抓包确认请求到底有没有到。tcpdump我跟人联调时偶尔会用不在生产环境轻易抓包流量大时抓包文件会瞬间膨胀拷走分析时记得用-w落盘避免直接在终端刷屏。4.3 文件传输scp与rsync部署代码、传输日志、备份数据都涉及服务器之间的文件传输# 从本地复制到远程服务器 scp /data/app.tar.gz user192.168.1.10:/data/ # 从远程服务器拉取文件到本地 scp user192.168.1.10:/data/app.log /tmp/ # rsync 增量同步适合大数据量重复传输 rsync -avz --progress /data/ user192.168.1.10:/data/scp适合一次性传输rsync的优势在于增量同步——只传输变更的部分大量重复传输时效率高出几个量级。rsync -avz几个参数的含义-a归档模式保留文件属性-v显示过程-z传输时压缩。5. 快捷操作与效率习惯从“会用”到“用好”到这一步基础命令基本覆盖完了后端开发日常的绝大多数场景。但命令掌握程度拉开差距的是是否形成了高效的操作习惯。同一个任务有人敲十几条命令查来查去有人一条组合命令直接出结果区别就在这里。5.1 组合命令与管道把多个命令串联成一条管道符|是 Linux 命令组合的灵魂。把上一个命令的输出作为下一个命令的输入一条命令就能完成多步操作# 查看日志中某个接口的平均响应时间 cat access.log | awk {sum$NF; count} END {print sum/count} # 找出访问量最高的前10个IP cat access.log | awk {print $1} | sort | uniq -c | sort -rn | head -n 10 # 查看当前目录下占用空间最大的5个文件 find . -type f -exec du -h {} \; | sort -rh | head -n 5第一眼看上去可能有点唬人拆开看每一步都很简单。比如第二条awk {print $1}把访问日志的 IP 字段提出来sort排序让相同 IP 相邻uniq -c统计每个 IP 出现次数sort -rn按次数倒序排列head -n 10取前 10 个。链路清晰一步到位。5.2 别名与历史命令让高频操作变成肌肉记忆有些命令组合每次使用都要敲一长串可以把它们配置成别名永久生效# 在 ~/.bashrc 里添加 alias llls -lh --colorauto alias gpsps -ef | grep alias netportnetstat -tlnp | grep配置完后执行source ~/.bashrc立即生效。gps java等价于ps -ef | grep javanetport 8080等价于netstat -tlnp | grep 8080每天至少省几十次按键。历史命令也有技巧# 搜索历史命令输入关键字即可 Ctrl R # 执行上一条命令 !! # 执行历史中序号为 N 的命令 !N!!的典型场景是sudo权限不足执行失败重新敲一遍太长直接sudo !!搞定。5.3 实用小技巧从实操中沉淀的效率工具最后分享几个零散但很高频的小技巧。快速创建目录结构mkdir -p /data/app/{logs,conf,bin,backup}一条命令创建多层级目录比mkdir逐个建高效太多。快速返回上一个目录cd -在 A 目录和 B 目录之间来回切换时cd -代替重复输入完整路径。历史命令去重查看history | awk {print $2} | sort | uniq -c | sort -rn | head这个命令能统计你最常敲的命令定期看一眼就知道自己的操作习惯也能发现哪些高频命令值得做成别名。定时执行命令watch -n 2 ps -aux | grep java每 2 秒自动刷新一次命令输出适合盯着某个进程的资源变化或某个日志文件的增长。6. 排查实录一次“服务假死”问题的完整命令链说了这么多散点命令最后用一次实际排查案例把整个流程串起来。某次线上反馈某个服务接口响应时间从 50ms 飙升到 5 秒但没有完全不可用。第一步登录服务器先看整体负载top看到load average到了 8.5而机器只有 4 核负载明显异常。进程列表里有个进程 CPU 占用到了 300%多核记下 PID。第二步确认这个进程是不是我们的服务ps -ef | grep PID grep -v grep确认是核心业务服务的进程。第三步查看日志定位具体问题tail -n 500 app.log | grep -E Exception|ERROR | tail -n 50看到频繁出现“连接池获取连接超时”的报错基本判断是数据库连接池被打满了。第四步查看数据库连接情况netstat -tlnp | grep 3306发现大量TIME_WAIT状态的连接说明应用频繁创建和断开数据库连接连接复用机制没有生效。第五步查数据库服务的连接数上限配置发现连接数配置偏小而应用侧连接池大小配置过大两者不匹配导致连接池等待。最终解决方案是调整连接池大小同时优化代码里部分未能正确释放连接的逻辑。整个排查过程用时约 15 分钟全部靠的是最基础的top、ps、tail、grep、netstat并没有任何高深命令。这个案例想说明一件事后端排查 Linux 问题真正的瓶颈从来不是命令不够多而是能不能根据症状快速选对命令、看懂输出、串联线索。把上面这些命令熟练到肌肉记忆的程度遇到线上问题才不会慌。我个人经验是Linux 命令的学习不要追求“背全”而是把日常最高频的二三十个命令用熟、用透理解每个输出字段的含义再配合管道组合出适合自己业务的快捷命令。时间长了这些工具就会像吃饭喝水一样自然那时候你就不再需要看任何命令手册了。
