Linux网络与监控图解 — Linux命令图解

网络命令/top监控/磁盘/内存/排障流程/线上避坑 · SVG可视化 + 生活类比 + 真实输出

🔴 真实事件：线上服务502，排查3小时才发现是磁盘满了

周三晚上11点，监控告警：API返回502 Bad Gateway。

23:05 运维重启了Nginx和Java应用 → 5分钟后又502

23:30 看Java日志：java.io.IOException: No space left on device

23:35 df -h 一看：/分区 100%满了！du -sh /var/log/* 发现app.log占了45GB

23:40 删了旧日志，重启服务恢复。但已经影响了1小时线上服务

💡 教训：排障必须系统化——先df -h看磁盘，再free -h看内存，再top看CPU。不要上来就重启！

① 网络命令

网络命令 = 各种通信工具：
• ping = 打电话试通不通（能响就通）
• curl = 寄快递试服务（发请求看响应）
• netstat/ss = 查电话簿（谁在跟谁通话）
• nslookup/dig = 查114号码（域名→IP）
• telnet/nc = 试门能不能推开（端口通不通）
• tcpdump = 录音监听（抓包分析）

terminal — 网络命令实战

# 1. ping — 测试网络连通性 $ ping -c 3 10.0.0.1 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.123 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.098 ms # --- 3 packets transmitted, 3 received, 0% loss --- # 2. curl — 测试HTTP服务 $ curl -v -o /dev/null -s -w "HTTP:%{http_code} Time:%{time_total}s\n" http://api.example.com/users < HTTP/1.1 200 OK HTTP:200 Time:0.234s # 3. ss — 查看端口监听（替代netstat） $ ss -tlnp | grep 8080 LISTEN 0 128 *:8080 *:* users:(("java",pid=12345,fd=12)) # ↑状态 ↑backlog ↑端口 ↑进程名/PID # 4. nslookup — DNS解析 $ nslookup api.example.com Server: 8.8.8.8 Name: api.example.com Address: 93.184.216.34 # 5. nc — 测试端口连通性 $ nc -zv db-server 3306 Connection to db-server 3306 port [tcp/mysql] succeeded!

② top/htop监控

load average怎么看？
• 值 < CPU核数 = 正常（比如4核机器，load < 4就行）
• 1分钟 >> 5分钟 > 15分钟 = 突然变忙（刚出问题）
• 1分钟 < 5分钟 < 15分钟 = 在恢复（问题在改善）
• 三个值差不多 = 稳定状态（或持续高压）

top快捷键速查：
• Shift+P：按CPU排序（最常用）
• Shift+M：按内存排序
• c：显示完整命令行
• 1：展开每个CPU核心的使用率
• top -Hp PID：查看某进程的线程级CPU使用（定位Java热点线程必备）

③ 磁盘与内存监控

$ # === 磁盘监控 === $ df -h # 查看磁盘使用率 Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 35G 15G 70% / /dev/sdb1 200G 120G 80G 60% /data tmpfs 3.9G 0 3.9G 0% /dev/shm # ⚠️ Use% > 80%要警惕，>90%可能影响服务 $ du -sh /var/log/* # 查看各目录大小 2.5G /var/log/app 1.2G /var/log/nginx 500M /var/log/mysql $ du -sh /var/log/* | sort -rh | head -5 # 排序取TOP5 $ iostat -x 1 3 # IO统计(每秒1次,共3次) Device rrqm/s wrqm/s r/s w/s rMB/s wMB/s await %util sda 0.00 5.00 10.0 20.0 0.05 0.10 2.50 1.50 # ↑平均IO等待(ms) ↑设备利用率 # await > 10ms = IO慢 %util > 80% = 磁盘繁忙 $ # === 内存监控 === $ free -h total used free shared buff/cache available Mem: 7.6Gi 5.3Gi 1.2Gi 256Mi 1.1Gi 2.3Gi Swap: 2.0Gi 248Mi 1.8Gi # ⚠️ 看available不是看free！available=free+可回收cache # Swap used高 = 物理内存不够，用了交换空间=变慢！ $ vmstat 1 5 # 虚拟内存统计 procs -----------memory---------- ---swap-- -----io---- r b swpd free buff cache si so bi bo 2 0 248000 1234567 234567 890123 5 2 20 15 # r=等待运行的进程 b=不可中断睡眠(等IO) # si=从swap进来 so=到swap出去 si/so高=内存紧张！

指标	正常	警告	危险	类比
磁盘Use%	<70%	70-85%	>85%	办公室快满了
iostat await	<5ms	5-10ms	>10ms	等快递太久
Swap used	<10%	10-30%	>30%	借了隔壁的办公室
Memory avail	>30%	10-30%	<10%	空闲工位很少
Load average	<核数	1-2×核数	>2×核数	员工排队等CPU

④ 排障流程

⑤ 线上三大陷阱 ❌✅

陷阱1: 磁盘满了导致服务异常

❌ bad-disk-full.sh — 磁盘满了还在重启服务

# ❌ 陷阱：502就重启，不查磁盘 $ systemctl restart my-app $ curl http://localhost:8080/health 502 Bad Gateway $ systemctl restart my-app # 再重启 $ curl http://localhost:8080/health 502 Bad Gateway # 还是502！ # 为什么？因为磁盘满了，应用写不了临时文件/日志 # 重启也写不了，当然还是502 # 而且磁盘满还可能导致数据库崩溃！

✅ good-disk-full.sh — 先查磁盘，再处理

# ✅ 正确：先看磁盘，再处理 # 第1步：查磁盘 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 50G 0 100% / # ↑ 磁盘100%！ # 第2步：找大文件 $ du -sh /var/log/* | sort -rh | head -5 45G /var/log/app/app.log # ← 45G！ 1.2G /var/log/nginx/access.log # 第3步：清理日志（不删除文件，清空内容） $ > /var/log/app/app.log # 清空文件但保留inode # 或者用 logrotate 配置自动轮转 # 第4步：重启服务 $ systemctl restart my-app $ curl http://localhost:8080/health 200 OK # ✅ 恢复了！ # 第5步：治本 — 配置logrotate防止再满 # /etc/logrotate.d/my-app # /var/log/app/*.log { # daily # 每天轮转 # rotate 7 # 保留7天 # compress # 压缩旧日志 # missingok # 日志不存在不报错 # }

陷阱2: OOM(内存溢出)只知道重启

❌ bad-oom.sh — OOM就重启，重启完还OOM

# ❌ 陷阱：OOM就重启，不dump不分析 $ kubectl get pods my-app-7d9f8 OOMKilled 0/1 Completed $ kubectl delete pod my-app-7d9f8 # 等新Pod起来 $ kubectl get pods my-app-8a2e1 OOMKilled 0/1 Completed # 还是OOM！内存泄漏还在，重启多少次都一样 # 而且没有dump，根本不知道什么对象占满了内存

✅ good-oom.sh — 先dump再重启，分析根因

# ✅ 正确：先dump再重启，分析根因 # 预防：启动参数加HeapDumpOnOutOfMemoryError # JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError # -XX:HeapDumpPath=/tmp/heapdump.hprof # -Xmx512m" # OOM发生后，先拿dump文件 $ kubectl cp my-app-8a2e1:/tmp/heapdump.hprof ./heapdump.hprof # 用MAT(Memory Analyzer Tool)分析dump # 1. 打开heapdump.hprof # 2. 看"Leak Suspects"报告 → 哪个对象占内存最多 # 3. 看"Dominator Tree" → 谁持有了这些对象 # 4. 定位代码中哪里创建了泄漏对象 # 常见OOM原因和解决： # • HashMap无限增长 → 加淘汰策略/限流 # • ThreadLocal没remove → 用完必须remove # • 大查询一次加载全部数据 → 分页查询 # • 连接池泄漏 → 用连接池框架，别自己管理 # 治本：找到泄漏原因后再部署新版本 # 如果是内存不够（不是泄漏），加大-Xmx

陷阱3: CPU飙高只知道加机器

❌ bad-cpu-high.sh — CPU高就加机器/重启

# ❌ 陷阱：CPU高就加机器，不查原因 $ top -bn1 | head -5 load average: 15.6, 12.3, 8.9 # 4核机器load 15！ $ kubectl scale deployment my-app --replicas=5 # 从2个Pod扩到5个，CPU确实降了 # 但如果代码里有死循环/正则回溯？ # 5个Pod全都在死循环，浪费3倍资源！ # 而且没找到根因，下次流量一来还会飙

✅ good-cpu-high.sh — 4步定位热点代码

# ✅ 正确：4步定位热点代码 # 第1步：找到Java进程PID $ top -c # 看完整命令行 PID USER %CPU COMMAND 12345 app 98.5 java -jar app.jar # 第2步：找到最耗CPU的线程 $ top -Hp 12345 # 线程级CPU PID USER %CPU COMMAND 12350 app 95.2 "http-nio-8080-exec-5" # 第3步：线程ID转十六进制 $ printf "%x\n" 12350 303e # 第4步：在线程dump中找该线程 $ jstack 12345 | grep 0x303e -A 30 "http-nio-8080-exec-5" #12350 prio=5 os_prio=0 tid=0x... nid=0x303e runnable java.lang.Thread.State: RUNNABLE at com.app.service.RegexUtils.validate(RegexUtils.java:42) at com.app.controller.OrderController.create(OrderController.java:89) # ← 找到了！RegexUtils.validate()在正则回溯！ # 解决：优化正则或加超时限制

📋 线上三大陷阱速查表

陷阱	❌ 错误做法	✅ 正确做法	一句话口诀
磁盘满→502	反复重启服务	df -h→du -sh找大文件→清空→logrotate治本	先看磁盘再重启！
OOM	重启了事，没dump	HeapDumpOnOutOfMemoryError→MAT分析→修泄漏	先dump再重启！
CPU飙高	加机器/扩容	top -Hp→printf %x→jstack定位热点线程	先找热点再扩容！

线上排障3个必备JVM参数：
1. -XX:+HeapDumpOnOutOfMemoryError：OOM时自动dump堆内存
2. -XX:HeapDumpPath=/tmp/heapdump.hprof：dump文件路径
3. -XX:+PrintGCDetails -XX:+PrintGCDateStamps：打印GC日志
这3个参数在OOM/GC频繁时能救命！生产环境必须配，不要等出了问题再配。

⑥ 面试速答

load average的3个数字分别代表什么？多少算高？

3个数字分别是过去1分钟、5分钟、15分钟的系统负载平均值。

多少算高？取决于CPU核数。4核机器：load < 4正常，4-8偏高，>8严重过载。

判断逻辑：
- 三个值差不多 = 稳定状态
- 1分钟 >> 5/15分钟 = 刚出问题
- 1分钟 << 5/15分钟 = 问题在恢复

free命令中available和free有什么区别？

free：完全没被使用的内存。
available：可用内存 = free + 可回收的buff/cache。

Linux会把空闲内存用作磁盘缓存(buff/cache)，当应用需要内存时，这些缓存会自动释放。所以available才是真正的可用内存。

类比：free=完全空的工位，available=空工位+随时可腾出来的临时工位。

磁盘满了怎么快速排查？

3步排查：
1. `df -h` → 看哪个分区满
2. `du -sh /* | sort -rh | head -10` → 看哪个目录最大
3. `du -sh /var/log/* | sort -rh | head -10` → 继续深入

常见原因：
- 日志文件太大 → `find /var/log -name "*.log" -size +100M`
- 已删除但进程仍占用的文件 → `lsof | grep deleted`
- Docker镜像/容器 → `docker system df`

top命令中wa(IO Wait)高说明什么问题？

wa高 = CPU在等磁盘IO完成。不是CPU不够，是磁盘太慢。

常见原因：
1. 磁盘性能差（机械硬盘跑重IO应用）
2. MySQL大量随机IO（缺少索引的全表扫描）
3. 日志狂写（应用疯狂打日志）

解决方案：
- 加SSD / 优化查询加索引 / 减少日志量

ss和netstat有什么区别？为什么推荐ss？

netstat：老牌工具，读取/proc/net信息，连接数多时很慢。
ss：直接读取内核socket数据结构，速度快很多，信息更全。

生产环境万级连接时：netstat可能要十几秒，ss秒出。

常用命令对照：
- `ss -tlnp` = `netstat -tlnp`（TCP监听端口）
- `ss -s` = 连接统计概要
- `ss -tn state established` = 所有已建立连接

Java应用CPU飙高怎么排查？

4步定位：
1. `top -c` → 找到Java进程PID（确认是Java进程）
2. `top -Hp PID` → 找到占用CPU最高的线程ID（如TID=12350）
3. `printf "%x\n" 12350` → 十进制转十六进制（0x303e）
4. `jstack PID | grep 0x303e -A 30` → 在线程dump中找到该线程在干啥

常见原因：死循环、正则回溯、GC频繁、加密运算。

Swap空间频繁使用说明什么问题？

Swap频繁使用 = 物理内存不够了，系统把数据从内存搬到磁盘（swap out），需要时再搬回来（swap in）。磁盘比内存慢1000倍！

用`vmstat 1`看si/so列：持续大于0说明在频繁swap。
用`free -h`看Swap used是否在增长。

解决方案：
1. 增加物理内存
2. 减少应用内存占用（优化/减少缓存）
3. 调整swappiness：`sysctl vm.swappiness=10`（尽量不用swap）
4. 注意：k8s环境建议swappiness=0或直接关闭swap

线上服务突然变慢，你怎么排查？

按"医生看病法"5步走：

1. 量体温：`top -c`看整体load/CPU/内存/wa
2. 问症状：`tail -200f app.log`看ERROR/OOM/Timeout
3. 查血象：`free -h`内存 / `df -h`磁盘 / `iostat -x 1` IO
4. 精准定位：CPU高→`top -Hp + jstack`，内存高→`jmap -heap`，网络→`ping/curl/tcpdump`
5. 治疗：根据根因处理（修代码/加资源/改配置）

面试加分：强调"先看整体指标再定位具体问题"，不要说"我直接重启"。

🎯 Linux网络与监控速记三原则

排障先看整体：top→free→df→iostat，不要上来就重启或看代码
看available不看free：Linux内存可用看available，free低不代表内存不够
线上必备3个JVM参数：HeapDumpOnOutOfMemoryError + HeapDumpPath + PrintGCDetails

🌐 Linux网络与监控图解

① 网络命令

② top/htop监控

③ 磁盘与内存监控

④ 排障流程

⑤ 线上三大陷阱 ❌✅

陷阱1: 磁盘满了导致服务异常

陷阱2: OOM(内存溢出)只知道重启

陷阱3: CPU飙高只知道加机器

⑥ 面试速答