Linux 实用命令速查与生存指南
服务器出事、SSH 上去两眼一抹黑?本文给开发者的 Linux 生存包:日常文件/文本处理命令、进程与资源排查(top/htop/lsof/df)、网络排查(curl/ss/netstat)、管道与重定向、以及出事时的排查思路(先看资源、再看进程、再看日志),让你在 Linux 上不再慌。
本文要点
- 主题聚焦:DevOps
- 适合人群:独立开发者、全栈工程师、AI 应用开发者
- 核心价值:快速理解背景、实践路径、常见误区和工程建议
线上告警来了,SSH 上去面对一个黑乎乎的终端,很多人就慌了。平时 IDE 里点点点,真到了排查现场,你会发现:会写代码和会排障是两件事。前者靠脑子,后者还得靠手上的命令。
这篇文章不是 man page 翻译,是写给开发者的 Linux 生存包:常用命令 + 排查思路。读完你能在服务器上不慌不忙地找到问题。
一、为什么开发者必须懂点 Linux 命令
三个理由,按重要性排序。
第一,服务器排障。容器化之后大家更习惯 docker exec 进去,但本质还是 Linux。日志在哪、端口被谁占了、内存是不是吃满了、CPU 谁在烧——这些问题的答案都在命令行里。不会命令,你只能求助于 SRE,而 SRE 不一定立刻有空。
第二,效率。一个 5GB 的日志文件,要找出昨天 14 点到 15 点之间所有 ERROR,用 IDE 打开都要半分钟,grep 一行命令两秒出结果。Linux 命令组合起来威力巨大,熟练之后再也回不去。
第三,面试和工作流转。中高级岗位的系统设计、SRE、平台工程、后端,都会问 Linux。问的不是"背诵所有参数",而是"线上 CPU 飙高你怎么排查"。这种题答得磕磕巴巴,基本就 pass 了。
所以下面这些命令,值得你认真过一遍,不是收藏夹吃灰那种。
二、文件与文本:find / grep / 管道与重定向
1. find:找文件
# 在当前目录递归找所有 .log 文件
find . -name "*.log"
# 找 7 天前修改过的日志(适合清理)
find /var/log -name "*.log" -mtime +7
# 找大于 100MB 的文件(磁盘满了常用)
find / -type f -size +100M 2>/dev/null
# 找到后直接删
find /tmp -name "*.tmp" -delete
2>/dev/null 把权限不足的报错丢掉,find 跑全盘必备。-mtime +7 是"修改时间超过 7 天",-mmin -5 是"5 分钟内改过",排查"刚刚谁改了文件"很有用。
2. grep:找内容
# 在文件里搜关键词
grep "ERROR" app.log
# 递归搜当前目录所有文件,显示文件名
grep -rn "timeout" src/
# 不区分大小写,只输出匹配部分
grep -ioE "https?://[^ ]+" access.log
# 反向匹配 + 显示行号
grep -vn "INFO" app.log
-r 递归,-n 显示行号,-i 忽略大小写,-v 反向,-E 用扩展正则,-o 只输出匹配部分。这六个参数记牢,grep 你就会 80%。
3. 管道 | 与重定向 > >>
这是 Linux 命令行真正强大的根源——每个命令都是一个小工具,管道把它们串成流水线。
# 找出日志里出现次数最多的 IP(top 10)
grep -oE "[0-9.]+" access.log | sort | uniq -c | sort -rn | head
# 把命令输出存到文件(覆盖)
ls -la > files.txt
# 追加而不是覆盖
echo "done" >> deploy.log
# 标准错误也存进去(2>&1)
npm run build > build.log 2>&1
记住:看到任何复杂任务,先想"能不能拆成几个命令串起来"。这比写脚本快十倍。
三、进程与资源:top / htop / ps / kill / lsof
1. top 与 htop:看整体资源
top # 实时看 CPU/内存,按 P 按 CPU 排序,M 按内存排序
htop # top 的升级版,彩色+鼠标,装上就回不去
top 一打开先看三件事:load average(右上角,三个数分别是 1/5/15 分钟平均负载,超过 CPU 核数就过载了)、CPU 行的 idle(剩余多少)、内存行的 free。
按 1 展开每个 CPU 核心,按 H 显示线程级别,按 c 显示完整命令行。这三个键是我最常用的。
2. ps:看进程快照
ps aux | grep node # 经典组合,看所有 node 进程
ps -ef --forest # 带父子关系树
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head
排查"哪个进程吃 CPU",ps -eo ... --sort=-%cpu | head 一行搞定。
3. kill:发信号
kill 12345 # 默认发 SIGTERM,优雅退出
kill -9 12345 # SIGKILL,强制杀,进程没法清理,慎用
killall node # 按名字杀所有 node
pkill -f "npm run" # 按完整命令行匹配杀
-9 是最后手段。先 kill(给进程机会清理),不行再 -9。
4. lsof:谁占了文件/端口
lsof -i :8080 # 谁在监听 8080 端口(端口被占用排查神器)
lsof -i # 所有网络连接
lsof +D /var/log # 谁在写 /var/log 目录
lsof -p 12345 # 进程 12345 打开的所有文件
"Address already in use" 这报错一出,lsof -i :端口 立刻定位元凶。装不上的话,ss -tlnp | grep 端口 也能看。
四、磁盘与内存:df / du / free
df -h # 看各分区使用率,-h 人类可读
df -i # 看 inode 使用率(磁盘没满但写不进文件,八成是 inode 满了)
du -sh /var/log # 看某个目录总大小
du -h --max-depth=1 /var | sort -h # 一层一层找谁占的多
free -h # 看内存,关注 available 而不是 free
几个常见坑:
- 磁盘满了先看
df -h,定位是哪个分区。再du -h --max-depth=1 | sort -h一层层钻进去,找大文件。 free看available,不是free。Linux 会把空闲内存拿去做磁盘缓存(buff/cache),这部分需要时会自动释放,所以free少不代表内存紧张。- inode 满了是隐藏 bug:磁盘还有空间,但创建文件报错 "No space left"。
df -i一看 inode 用满,通常是某个目录堆了几百万个小文件。
五、网络:ss / netstat / curl / ping / tcpdump
1. 端口与连接
ss -tlnp # 现在的标配,看监听端口(比 netstat 快)
ss -tan state established # 看已建立的连接
netstat -tlnp # 老牌工具,没装 ss 时用
ss 是 netstat 的替代品,现代发行版默认就有。-t TCP、-u UDP、-l 监听、-n 不解析域名(快)、-p 显示进程。
2. curl:HTTP 请求
curl -i https://api.example.com/health # 带响应头
curl -X POST -d '{"k":"v"}' -H "Content-Type: application/json" URL
curl -w "%{http_code} %{time_total}s\n" -o /dev/null -s URL # 只看状态码和耗时
curl --resolve api.example.com:443:1.2.3.4 https://... # 绕过 DNS 直接连指定 IP
-w 自定义输出格式是排查慢接口的利器:time_namelookup、time_connect、time_starttransfer 分别是 DNS、建连、首字节时间,一眼看出慢在哪一段。
3. 连通性
ping example.com # ICMP 连通性(有些防火墙禁 ICMP,ping 不通不代表不通)
traceroute example.com # 看每一跳路由,定位卡在哪一段网络
mtr example.com # traceroute 加强版,持续跑、看丢包率
4. tcpdump:抓包(终极武器)
sudo tcpdump -i any port 8080 -nn -c 100 # 抓 8080 端口 100 个包
sudo tcpdump -i eth0 host 1.2.3.4 -w out.pcap # 抓指定主机,写到文件用 wireshark 看
抓包是最后的手段。HTTP 看不出问题、SSL 握手失败、协议行为诡异——抓个包用 wireshark 一看便知。配合 strace -p PID 看系统调用,几乎没有查不出的疑难杂症。
六、文本三剑客:grep / sed / awk——日志排查神器
这三个命令是 Linux 文本处理的灵魂,单独用威力一般,组合起来堪比写代码。
grep(找)
上面讲过,核心是"过滤出含某模式的行"。
sed(改)
# 替换文件里所有的 foo 为 bar(原地修改)
sed -i 's/foo/bar/g' file.txt
# 只看第 10 到 20 行
sed -n '10,20p' app.log
# 删掉空行
sed -i '/^$/d' file.txt
-i 是原地修改,危险动作,改之前最好先不加 -i 跑一遍看输出对不对。
awk(处理列)
# access.log 第二列是 IP,统计每个 IP 出现次数
awk '{print $2}' access.log | sort | uniq -c | sort -rn | head
# 累加第三列(比如响应大小),算总流量
awk '{sum+=$3} END {print sum}' access.log
# 带条件:只统计状态码 >= 500 的请求
awk '$9 >= 500 {print $7}' access.log | sort | uniq -c | sort -rn
awk 把每行按空白切成字段($1、$2...),还能写条件和 END 块做汇总。日志分析里它是无可替代的。
三剑客组合示例——找出 500 错误最多的接口:
awk '$9 == 500 {print $7}' access.log | sort | uniq -c | sort -rn | head -10
这一行,抵得上写一个 Python 脚本。
七、出事排查思路:资源 → 进程 → 日志 → 网络
这是最重要的一节。命令记得再多,不知道先看哪个也白搭。我总结的四步法:
第一步:看资源。一上来先 top(或 htop)看 CPU、内存、load。再看 df -h 看磁盘。这三个数正常,排除一大半问题(磁盘满、内存爆、CPU 打满这三类最常见)。uptime 看负载和运行时间也顺手敲一下。
第二步:看进程。资源异常就深挖到进程。ps aux --sort=-%cpu | head 找烧 CPU 的,ps aux --sort=-%mem | head 找吃内存的。lsof -p PID 看这个进程在干啥。怀疑端口被占,lsof -i :端口 或 ss -tlnp 定位。
第三步:看日志。进程找到了,接下来看它在说什么。应用日志 tail -f app.log(实时)或 less +F app.log(可以往上翻)。系统服务用 journalctl:
journalctl -u nginx -f # 实时跟 nginx 日志
journalctl -u myapp --since "1 hour ago"
journalctl -p err # 只看 error 级别
dmesg -T 看内核日志——OOM killer 杀进程、磁盘报错都在这里,时间一长新手最容易漏掉。
第四步:看网络。前三步都没问题,才考虑网络。ss -tan 看连接状态(大量 TIME_WAIT 或 CLOSE_WAIT 是常见症状),curl -w 测接口耗时,ping / mtr 看链路,最后 tcpdump 抓包。
四步走完,90% 的故障都能定位。剩下的 10% 通常需要更深入的 profiling(perf、strace、火焰图),那是另一篇文章的事了。
一个反向忠告:别一上来就 tail -f 日志。资源没看就扎进日志海,你会在一万行 ERROR 里迷失方向。先确认是哪类问题(资源?进程?网络?),再去看对应的日志,效率高得多。
小结
- 命令是开发者的事,不是 SRE 的事。SSH 上服务器能独立排障,是中高级工程师的基本盘。面试里"线上 CPU 飙高怎么排查"这种题,答得利索就是分水岭。
- 管道是 Linux 的灵魂。
grep | sort | uniq -c | sort -rn | head这种组合,比写 Python 脚本快十倍。看到复杂任务先想"能不能串命令",而不是"打开 IDE"。 - 文本三剑客 grep / sed / awk 是日志排查神器。尤其 awk,按列处理 + 条件 + 汇总,日志分析无可替代。
- 资源排查记住三个数:load average、CPU idle、磁盘使用率。内存看
available不是free,inode 满了用df -i。 - 出事排查四步法:资源 → 进程 → 日志 → 网络。先
top/df,再ps/lsof,再journalctl/tail,最后ss/curl/tcpdump。顺序不能乱。
一句话收尾:Linux 命令不是为了考证,是为了在凌晨三点告警响起时,你能在五分钟内定位问题而不是抓瞎。 手上这几十条命令熟练了,你会发现所谓的"现场感"和"工程直觉",其实就是它们组合出来的肌肉记忆。
Related
相关推荐
文章
Docker 部署 Next.js 社区项目的注意事项
围绕 DevOps、Next.js 的技术趋势、工程实践和独立开发视角。
文章
OpenTelemetry 如何帮助你观察 AI 应用?
围绕 DevOps、AI 的技术趋势、工程实践和独立开发视角。
文章
长运行工具调用:Operation、Poll 与 Cancel 的终态协议
初始请求超时后,工具可能仍在服务端运行;发出取消也不等于副作用已停止。本文为单次长运行工具调用建立 operation 身份、轮询水位、取消竞态和唯一终态接受点。
文章
Agent 记忆删除传播:从用户遗忘请求到可验证清除
删除主表一行不会清掉向量、摘要、缓存和恢复后的备份。本文用删除状态机、代际墓碑、派生血缘与端到端 canary 验证真正遗忘。