凌晨两点手机运维群的告警声响了同事发来一串消息“服务器负载爆了CPU全红网站打不开快帮忙看看。”我打开终端一条命令一个结果十分钟定位到是凌晨的定时任务把进程池拉满又因为日志文件把磁盘写满了。整个过程用的全是Linux基础命令——网络、进程、磁盘、防火墙没上任何监控平台。事后我把这套排查流程整理成了一份自用笔记今天这篇文章就是它的完整版。这篇笔记适合所有Linux运维、后端开发、以及刚接手服务器的新手朋友。内容聚焦四块网络排查、进程管理、磁盘分析、防火墙规则每块都按“功能说明 常用命令 参数细节 实际踩坑”的结构来讲。学完之后至少能让你在接到服务器异常告警时不慌不忙地打开终端用一条条命令把问题从“模糊”推理到“确定”。1. 网络命令从连通性到数据包1.1 先看链路通不通ping 与 mtr排查网络问题的第一步永远是“通不通”。ping看的是ICMP协议的往返时延它只能确认最基础的连通性排查方向基本是这样的ping -c 4 8.8.8.8 # 测试外网连通性 ping -c 10 www.baidu.com # 测试DNS解析是否正常-c指定发送的包数量-i指定间隔秒数。如果ping 外网IP通但ping 域名不通那问题大概率出在DNS解析。如果ping通但业务端口连不上问题就往下走去查端口监听和防火墙。mtr是traceroute的增强版它结合了ping和traceroute持续显示到目标每一跳的丢包率和时延。排查“用户反馈某个地区访问很慢”的时候mtr是最好用的工具mtr -rw 203.0.113.5 # -r 报告模式-w 宽屏输出看Loss%列就能判断是哪一跳丢包。有个容易误判的点某些骨干网的ICMP请求在中间节点本身就是不响应的这时候要重点看“倒数第二跳”或“最后一跳”的Loss而不是中间某一跳的30%。1.2 端口与连接状态的真相ss 替代 netstat现在新装系统的时代netstat已经逐渐退出历史舞台ss作为它的全面替代速度更快信息更全。端口有没有起来、连接数涨没涨都是ss的老本行ss -lntp # 查看所有监听端口及对应进程 ss -antp # 查看所有TCP连接及对应进程 ss -s # 查看Socket统计摘要几个参数拆开讲-l只看LISTEN状态-n不解析域名直接显示IP-t只看TCP-p显示进程号。实战中判断“端口起没起来”用ss -lntp | grep 8080有输出就是起了没输出就是进程挂了或者绑定在别的网卡上。排查连接数飙高时ss -antp配合状态统计很好用。比如查看TIME_WAIT的数量ss -ant | awk {print $1} | sort | uniq -c这个命令的输出里如果TIME_WAIT数量多到千级别说明短连接大量创建Classic方案是考虑开启net.ipv4.tcp_tw_reuse。如果SYN_SENT很多说明发出去的重传没人应答多半是对端拒绝或者被防火墙拦了。这里要提醒一下排查连接状态时ESTABLISHED数量异常飙升往往不是“有人在攻击”而是“本地程序没做好连接复用”或“上游DBA没设置wait_timeout”先把自己程序的连接池配置捋一遍再谈防护。1.3 真正能抓包的工具tcpdump看完端口和连接再往深层走就是数据包本身了。tcpdump可能是Linux运维最值得花时间学习的命令因为它能看到最真实的网络交互能验证“是不是真的有请求过来”“返回了什么内容”。tcpdump -i eth0 tcp port 3306 -nn -s 0 -w mysql.pcap参数含义-i指定网卡tcp port 3306是过滤器表达式只抓3306端口的TCP包-nn不解析域名和端口名-s 0抓完整包不截断-w写入文件方便用Wireshark打开分析。现场排查时一般不建议直接-w更常用的是实时看包tcpdump -i eth0 host 10.0.0.88 and tcp port 80 -nn -c 100-c 100表示抓100个包自动停止。看到SYN发出去但始终没有SYN-ACK回来那基本可以断定目标服务器的防火墙在丢包。看到大量RST连接重置极可能是端口没监听或者防火墙主动reset掉非法连接。顺带说一个技巧两台机器之间网络“通不通”是一个层面“通到了哪一层”是另一个层面。用tcpdump在业务服务器上抓包如果连SYN都看不到走物理链路和虚拟化的交换机层面就有问题如果看到SYN但没回应问题在本地防火墙或应用没监听如果有三次握手但应用报错那才是真正的业务层问题。这种分层排查法配合tcpdump比看任何监控面板都准。1.4 网络测速与整体诊断思路热词里反复出现“网络测速”虽然生产服务器上不太有人天天测速但排查带宽跑满还是很有用的。iperf3是标准的带宽测试工具需要两端配合# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.10 -t 30 -P 4-P 4开四条并发流能测出接近真实的带宽上限。如果本地iperf3能跑满带宽但业务速度上不去那瓶颈就在中间的LB、防火墙规则或者后端应用的模型上。整体诊断思路按照这套流程走下来基本就清晰了先ping看通断再mtr看路径然后ss看端口最后tcpdump看包。一层一层排除不要一上来就抓包或者一上来就重启服务。实测排障中最忌讳的事就是“用重启解决问题”之后还要假装是配置不当导致的——重启掩盖的是真实故障下一次再爆发只会更难看。2. 进程命令找到谁在吃CPU、屯内存2.1 谁在跑ps 与 top 的正确打开方式进程排查的核心问题永远是三个谁在跑、吃多少资源、能不能动它。ps -ef最常用显示完整命令行配合grep找具体进程ps -ef | grep java但ps输出的是某一瞬间的快照要动态看进程状态靠top。top一进来是交互界面按P按CPU排序按M按内存排序按1看每个核心的负载。这些都是基础操作真正有用的参数是-p指定PID和-H显示线程top -Hp 12345 # 看进程内部每个线程的资源占用这个命令重要在哪Java应用CPU飙高时你看top只能看到一个java进程整体占400%根本不知道是哪个线程在搞事情。加上-H后能看到具体线程TID再用printf %x\n 12346 # 把这个线程ID转成十六进制然后在jstack 12345 | grep nid0x3012里找到对应线程的堆栈就能定位到是哪段代码在跑。这套组合是Java服务排障的基本功我几乎每周都会用到。uptime也有说法它的load average三个数字分别代表1分钟、5分钟、15分钟的平均负载。如果1分钟远大于15分钟说明系统在短时间涌入大量任务持续高要不就是CPU被算满要不就是不可中断的IO等待把进程按住了。但注意load高不一定是CPU问题D状态进程堆积、磁盘IO遇到慢盘都会让load虚高。2.2 处理失控进程kill 家族的讲究找到失控进程后怎么“动手”也有讲究。kill是发信号不是“杀”。最温和的是TERM(15)让进程自己清理退出顽固的就用KILL(9)那是让内核直接回收不给善后机会kill -15 12345 # 优雅退出 kill -9 12345 # 强制结束 pkill -f php artisan queue # 按命令行匹配杀一批pkill -f杀伤面很大匹配的是完整命令行。如果你写pkill -f queue可能把不相关的进程也带走。用过一次教训深刻本想清掉老旧的Python爬虫结果把同事测试队列的脚本全毙了。建议pkill前先pgrep -f预览一下匹配结果确认再动手。还有一种杀不掉的进程叫Zombie僵尸态。它的父进程没有调用wait()回收所以PID还占着。直接kill -9僵尸都没用僵尸不是“活着”是“等着被收尸”只能找到它的父进程让父进程重启或退出才能彻底回收。这个知识点面试和工作里被问到的概率相当高。如果服务器上突然冒出一堆僵尸优先排查它们的父进程是不是有Bug没做异常处理而不是盯着僵尸本体打转。2.3 深入内部strace 与 lsof有时候进程CPU不高、内存也不炸但就是“卡住”不干活。这时候该用strace去跟踪它到底阻塞在哪个系统调用上strace -p 12345 -f -e tracefile,network-p指定PID-f跟随子线程-e限定跟踪哪些类型的系统调用。如果看到程序卡在某个connect或者read上长时间不动那就是在等网络响应或等锁。我看过一次PHP-FPM大量进程阻塞在fsync上一查是磁盘是普通数据盘而非SSD慢IO把所有PHP进程全拖住了替换掉慢盘立刻恢复。lsof用来查看进程打开的句柄特别是排查“进程占用但删不掉的文件”lsof -p 12345 | grep deleted如果发现Java进程打开了很多deleted状态的日志文件那就意味着磁盘空间被写满日志文件被删了但进程没释放句柄空间仍然占着。这是经典的“df看到空间100%但du看不到大文件”的场景。处理方式就是重启这个进程或者让应用重新open日志文件。这个坑我踩过不止一次所以专门把它写进这句命令的备注里。2.4 systemd 时代的进程管理现在的Linux发行版基本都是systemd全家桶。systemctl不仅管服务也是查进程的入口之一systemctl status nginx # 看服务状态、主进程PID、最近日志 systemctl list-units --typeservice --staterunning # 看所有运行中的服务 systemctl restart nginx # 重启服务systemctl status那段输出里最下面几行是journald记录的最近日志很多系统级错误不需要去翻/var/log/就能直接看到。排查开机启动项和异常自启进程时用这两个命令systemctl list-unit-files --typeservice --stateenabled systemctl list-unit-files --typeservice --statefailed热词中反复出现“进程通信IPC”在systemd、nginx、PostgreSQL这些服务里进程间通信方式直接关系着性能表现。排查时可以顺手看一下System V IPC和POSIX共享内存的使用情况ipcs -a # 查看所有共享内存、信号量、消息队列 ipcs -l # 查看大小限制如果一个服务异常崩溃却留下一堆没人释放的信号量或共享内存其他实例启动时会报“资源不可用”。ipcs -s看一眼剩余数量再用ipcrm -s 信号量ID手动清掉。这个场景在跑Oracle和PostgreSQL多实例的机器上不算少见值得记住。3. 磁盘命令从空间告警到IO瓶颈3.1 空间去哪了df 与 du 的区别磁盘告警是最常见的运维工单。df -h看文件系统空间du -h看目录占用大小df -h du -sh /var/log du -sh /data/*df和du的区别要想清楚df是文件系统层面的统计走的是超级块里的元数据du是逐个目录、逐个文件累加的大小。比例失调是常有的事。比如之前说的日志文件被删除但进程没释放句柄df显示/100%du -sh /只显示用了40%中间那60%被deleted文件占着。遇到这种“空间神秘消失”的情况排查方向别瞎猜直接执行lsof L1 | grep deleted找出所有被删除但仍被占用的文件优先看哪几个进程的file对象占用最大对应处理。日常巡检空间增长我固定用两招。第一招是快速定位顶层吃空间的目录du -h --max-depth1 / 2/dev/null | sort -hr | head -20--max-depth1只统计当前目录下一级子目录大小sort -hr按人类可读的数值倒序排一眼看出谁最大。第二招是查超过100M的大文件find / -type f -size 100M -exec ls -lh {} \; 2/dev/null这套组合对日志爆盘、备份文件堆积、临时文件忘清理都有奇效。3.2 inode 耗尽与文件数量飙升还有一类磁盘告警很容易被忽略——df -h明明还有剩余空间但系统就是提示No space left on device。这时要看的不是block是inodedf -iinode是文件系统存储文件元信息的索引节点。如果inode被占满即使磁盘还有几个G也一个文件都建不了。常见元凶是/tmp下垃圾小文件堆了几十万个或者某个程序在循环写缓存但没有清理逻辑。排查和清理find /tmp -type f | wc -l # 统计文件数量 find /tmp -type f -mtime 7 -delete # 删除7天前的文件如果不确定能不能删先find /tmp -type f -mtime 7 | head -50看看文件名再决定是不是安全的临时文件。inode问题一旦发生影响是全局性的连日志都写不进去排错环境特别恶劣所以我对容易产生海量小文件的应用路径会提前做规划比如单独分区、限制inode数量上限、或者用文件系统特性规避占用。3.3 IO 性能分析iostat 与 iotop如果服务本身不算慢但整体吞吐就是上不去很可能是磁盘IO顶到了瓶颈。iostat是分析磁盘IO最实用的统计工具iostat -x 1 5参数含义-x显示扩展统计1 5表示每秒刷新一次共采集5次。重点看%util设备利用率、await平均IO响应时间、r_await/w_await读/写延迟。一台读写正常的SSDawait通常在几毫秒级别如果w_await上百毫秒说明写入链路有严重问题——可能是磁盘降速、RAID重建中、或者劣质虚拟磁盘。%util达到100%并不总代表“坏”可能只是峰值负载瞬时打满。要结合svctm和队列长度看如果队列长时间超过硬盘的queue depth还有大量IO等待那就真的是瓶颈了。只看iostat还不够直观的时候用iotop直接看哪个进程在使劲读写iotop -oP # 只显示有IO操作的进程-o只显示活跃进程-P只显示进程不显示线程。如果看到某个java进程持续在DISK WRITE十几MB/s那你基本可以判断它在疯狂flush数据或写日志顺着这条线索去查程序配置比在应用层猜半天要高效得多。3.4 LVM 扩容与磁盘初始化磁盘用着用着不够用扩分区是运维必修课。如果是KVM/VMware虚拟机先在虚拟化平台给磁盘扩容再在系统里用fdisk扩大分区和pvresize同步LVMfdisk -l /dev/sda # 看当前分区表 pvresize /dev/sda1 # 在线扩大物理卷 lvextend -L 20G /dev/mysql/data # 给逻辑卷加20G xfs_growfs /dev/mysql/data # XFS文件系统在线扩容如果是ext4最后一步换成resize2fs /dev/mysql/data。顺序不能反一定要先扩PV再扩LV再扩文件系统。我试过跳过pvresize直接lvextend直接报Insufficient free space后来才想起来PV没同步白折腾十分钟。论坛里有人问“磁盘必须经过初始化 逻辑磁盘管理器才能访问”其实就是Windows下的磁盘初始化问题对应到Linux就是新加数据盘后要fdisk建分区、mkfs建文件系统、mount挂载。Linux新数据盘上线步骤简单记一下lsblk # 确认新磁盘盘符 fdisk /dev/sdb # n新建分区, p主分区, w保存 mkfs.xfs /dev/sdb1 # 建文件系统 mkdir -p /data mount /dev/sdb1 /data echo /dev/sdb1 /data xfs defaults 0 0 /etc/fstab # 永久挂载/etc/fstab写错会导致开机失败写完最好执行mount -a验证一遍没有报错再重启否则人不在机房的时候服务器挂了就真的只剩远程泪目了。4. 防火墙命令规则、状态与故障定位4.1 firewalld 日常操作现在的CentOS/RHEL系默认用的是firewalld底层封装了iptables。日常放行端口、查状态是最高频操作systemctl status firewalld firewall-cmd --list-all firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload--permanent是写进持久化配置不加这个参数的话重启后规则就没了。条件允许的情况下先用不带--permanent的命令试一阵确认功能正常再永久化reload否则一个失误的持久化规则可能会让远程连接直接断开。放行端口的粒度可以更细一点比如只允许指定来源IP访问firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port3306 protocoltcp accept这是运维里很实用的写法MySQL、Redis这类内网组件服务限IP访问比裸奔端口安全几个量级。4.2 iptables 规则本质与匹配顺序虽然有firewalld很多老服务或Docker环境仍然直接用iptables。熟悉iptables核心就是表、链、规则三个概念。iptables -L -n -v # 列出所有规则加 -v 看命中次数 iptables -t nat -L -n # 查看NAT规则 iptables -I INPUT 1 -s 10.0.0.5 -j DROP # 在INPUT链最前面插入一条规则的匹配顺序是所有排障的底层逻辑——从头到尾逐条匹配命中即执行不会再往下走。所以在-A INPUT -j REJECT放在最后、拒绝所有之前插入的ACCEPT白名单规则才会生效。这就像排队安检你插队排到第一个后面的人即便是VIP也得等你先过。最典型的坑是加白名单规则时用了-A追加到末尾结果前面的REJECT规则先拦住白名单完全无效。我早期就犯过这个错之后凡是加白名单一律用-I INPUT 规则号插到最前。还有一个隐藏概念要心里有底iptables的nat表有PREROUTING、POSTROUTING和OUTPUT链做端口转发和docker网络隔离全靠它。Docker容器网络不通时很多场景先别急着怀疑容器而是看一眼宿主机NAT规则的映射情况iptables -t nat -nL POSTROUTING如果看到MASQUERADE规则异常或者被清掉容器外联自然就废了。此时大概率是某个软件在重配iptables时把你的规则冲了。4.3 防火墙故障排查实战“用户说服务器访问不了你有三分钟定位问题”。我一般按这套流程来# 第一步看端口监听 ss -lntp | grep 80 # 第二步防火墙是否放行 firewall-cmd --list-all | grep 80 # 第三步iptables完整链路 iptables -L -n --line-numbers如果问题依然在用tcpdump在服务器上抓包tcpdump -i eth0 tcp port 80 -nn看到SYN有进无出马上检查防火墙规则看到SYN和SYN-ACK都正常再查应用日志。思路的顺序永远是“先链路、再端口、再进程、再应用层”而不是一上来就抓包看半天。热词里提到“防火墙黑白名单”firewalld和iptables天然就支持这种策略。黑名单场景是明确从某IP过来的恶意请求直接在INPUT链插入DROP规则iptables -I INPUT -s 203.0.113.99 -j DROP白名单场景则是“只允许公司IP访问SSH”可以先改sshd_config的AllowUsers配合防火墙做双重限制也可以只用防火墙单点实现。按我之前操作的经验落防火墙规则时顺手写注释是极好的习惯iptables -I INPUT -s 203.0.113.99 -j DROP -m comment --comment block scanner 2024-11-02等过段时间想清理规则时iptables -L --line-numbers配合注释能精准找到哪条对应什么。4.4 厂商防火墙与系统防火墙的差别热词里出现“华为防火墙配置命令”“锐捷防火墙配置”这些是硬件防火墙和Linux系统防火墙完全是两个层面的东西。硬防在网络边界Linux防火墙在主机内部两者都要管、都要熟。硬防的配置通常有独立的Web界面和命令行核心概念是安全区域、安全策略、NAT策略生产上一般由网络组负责。如果你刚接手一台服务器且网络不通先确认是不是边界硬防没放行再回来查自己的系统防火墙。很多“明明什么都配好了但连不上”的灵异事件最后都发现是硬防策略的老问题。Linux下的nftables是iptables的现代替代品新系统Ubuntu 22.04/Rocky 9默认已经采用。语法上不一样但排查思路一致nft list ruleset # 查看所有规则 nft add rule inet filter input ip saddr 203.0.113.99 drop # 添加一条阻止规则有iptables基础再上手nftables大概小半天就够了。遇到新系统查防火墙先用nft list ruleset看看全局别惯性用iptables -L发现半天没输出还以为规则被清光了。5. 高频故障排查速查表平时遇到的问题多了我习惯把高频故障整理成一张速查表贴在笔记开头遇到类似现象直接对号入座。这里也分享出来故障现象优先排查命令可能原因与处理方向外网IP能ping通域名ping不通cat /etc/resolv.conf、nslookup baidu.comDNS配置错误检查上游DNS与域名解析记录端口能通但业务超时ss -ant | awk {print $1} | sort | uniq -cTIME_WAIT堆积、连接池耗尽调整内核参数或连接池配置负载很高CPU却不忙top看D状态、iostat -x 1 3IO等待或慢盘拖累定位后替换磁盘或调整IO调度磁盘满了但du查不到大文件lsof L1 | grep deleted删除的文件被进程占用重启进程或让应用重开日志句柄进程杀不掉且状态为Zps -o ppid -p 僵尸PID僵尸进程处理父进程init收养的子进程基本是孤儿应用卡住且top显示正常strace -p PID -f -e tracefile,network阻塞在文件IO、网络等待或锁等待顺着调用栈定位容器外连不上但端口已监听iptables -t nat -nL POSTROUTINGNAT/DNAT规则丢失Docker链被重置重建规则新加规则不生效iptables -L -n --line-numbers规则插入位置不对白名单必须排在拒绝规则之前端口明明开着外面却访问不了firewall-cmd --list-all、tcpdump -i eth0 tcp port 端口系统防火墙未放行或硬防策略拦截按“链路→端口→防火墙”逐层排除这张表是给“半熟悉Linux的人”救急用的核心不是背下来而是理解每条命令背后的排查思路——先看链路、再看端口、然后规则、最后应用。思路比命令重要因为命令会忘思路不会。6. 我的体会与几条补充写到这里这份笔记的主体内容就分享完了。说说我自己在实际操作中的体会。刚接触Linux那几年总喜欢背命令觉得背得多就是厉害。后来踩的坑多了才明白命令只是一个抓手真正值钱的是“在什么场景下用哪条命令、输出代表什么问题、下一步该看什么”。比如本文反复提到的那套排查链连通性差看mtr连接异常看ss想确认真实数据交互用tcpdump每个工具的定位都完全不同互相替代不了。还有一条很重要的经验不要小瞧“自用笔记”的价值。我的这套命令整理从第一次写到现在已经迭代了四五年每次排障遇到新坑就往上补一行注释、一个新命令、一个误操作记录它越来越像一本“踩坑史”。建议你拿到这篇内容后也按照自己的实际环境去跑一遍命令把输出截下来贴到笔记里再补上你自己的业务相关路径和踩坑记录。环境不同细节不同但排障的底层逻辑是通用的。最后分享一个小技巧。排查完一个问题别急着收工花两分钟把“命令 输出 结论”存成一条Markdown记录。这个习惯坚持半年你积累的排障笔记会比任何官方文档都实用而且全是结合你自己业务的场景翻起来效率极高。下次再遇到同一个问题搜索自己的笔记五分钟定位比在群里问同事有效率得多。希望这篇“自用级”笔记也能成为你运维工具箱里顺手的那一把。 Linux服务器故障排查：网络、进程、磁盘与防火墙命令实战
凌晨两点手机运维群的告警声响了同事发来一串消息“服务器负载爆了CPU全红网站打不开快帮忙看看。”我打开终端一条命令一个结果十分钟定位到是凌晨的定时任务把进程池拉满又因为日志文件把磁盘写满了。整个过程用的全是Linux基础命令——网络、进程、磁盘、防火墙没上任何监控平台。事后我把这套排查流程整理成了一份自用笔记今天这篇文章就是它的完整版。这篇笔记适合所有Linux运维、后端开发、以及刚接手服务器的新手朋友。内容聚焦四块网络排查、进程管理、磁盘分析、防火墙规则每块都按“功能说明 常用命令 参数细节 实际踩坑”的结构来讲。学完之后至少能让你在接到服务器异常告警时不慌不忙地打开终端用一条条命令把问题从“模糊”推理到“确定”。1. 网络命令从连通性到数据包1.1 先看链路通不通ping 与 mtr排查网络问题的第一步永远是“通不通”。ping看的是ICMP协议的往返时延它只能确认最基础的连通性排查方向基本是这样的ping -c 4 8.8.8.8 # 测试外网连通性 ping -c 10 www.baidu.com # 测试DNS解析是否正常-c指定发送的包数量-i指定间隔秒数。如果ping 外网IP通但ping 域名不通那问题大概率出在DNS解析。如果ping通但业务端口连不上问题就往下走去查端口监听和防火墙。mtr是traceroute的增强版它结合了ping和traceroute持续显示到目标每一跳的丢包率和时延。排查“用户反馈某个地区访问很慢”的时候mtr是最好用的工具mtr -rw 203.0.113.5 # -r 报告模式-w 宽屏输出看Loss%列就能判断是哪一跳丢包。有个容易误判的点某些骨干网的ICMP请求在中间节点本身就是不响应的这时候要重点看“倒数第二跳”或“最后一跳”的Loss而不是中间某一跳的30%。1.2 端口与连接状态的真相ss 替代 netstat现在新装系统的时代netstat已经逐渐退出历史舞台ss作为它的全面替代速度更快信息更全。端口有没有起来、连接数涨没涨都是ss的老本行ss -lntp # 查看所有监听端口及对应进程 ss -antp # 查看所有TCP连接及对应进程 ss -s # 查看Socket统计摘要几个参数拆开讲-l只看LISTEN状态-n不解析域名直接显示IP-t只看TCP-p显示进程号。实战中判断“端口起没起来”用ss -lntp | grep 8080有输出就是起了没输出就是进程挂了或者绑定在别的网卡上。排查连接数飙高时ss -antp配合状态统计很好用。比如查看TIME_WAIT的数量ss -ant | awk {print $1} | sort | uniq -c这个命令的输出里如果TIME_WAIT数量多到千级别说明短连接大量创建Classic方案是考虑开启net.ipv4.tcp_tw_reuse。如果SYN_SENT很多说明发出去的重传没人应答多半是对端拒绝或者被防火墙拦了。这里要提醒一下排查连接状态时ESTABLISHED数量异常飙升往往不是“有人在攻击”而是“本地程序没做好连接复用”或“上游DBA没设置wait_timeout”先把自己程序的连接池配置捋一遍再谈防护。1.3 真正能抓包的工具tcpdump看完端口和连接再往深层走就是数据包本身了。tcpdump可能是Linux运维最值得花时间学习的命令因为它能看到最真实的网络交互能验证“是不是真的有请求过来”“返回了什么内容”。tcpdump -i eth0 tcp port 3306 -nn -s 0 -w mysql.pcap参数含义-i指定网卡tcp port 3306是过滤器表达式只抓3306端口的TCP包-nn不解析域名和端口名-s 0抓完整包不截断-w写入文件方便用Wireshark打开分析。现场排查时一般不建议直接-w更常用的是实时看包tcpdump -i eth0 host 10.0.0.88 and tcp port 80 -nn -c 100-c 100表示抓100个包自动停止。看到SYN发出去但始终没有SYN-ACK回来那基本可以断定目标服务器的防火墙在丢包。看到大量RST连接重置极可能是端口没监听或者防火墙主动reset掉非法连接。顺带说一个技巧两台机器之间网络“通不通”是一个层面“通到了哪一层”是另一个层面。用tcpdump在业务服务器上抓包如果连SYN都看不到走物理链路和虚拟化的交换机层面就有问题如果看到SYN但没回应问题在本地防火墙或应用没监听如果有三次握手但应用报错那才是真正的业务层问题。这种分层排查法配合tcpdump比看任何监控面板都准。1.4 网络测速与整体诊断思路热词里反复出现“网络测速”虽然生产服务器上不太有人天天测速但排查带宽跑满还是很有用的。iperf3是标准的带宽测试工具需要两端配合# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.10 -t 30 -P 4-P 4开四条并发流能测出接近真实的带宽上限。如果本地iperf3能跑满带宽但业务速度上不去那瓶颈就在中间的LB、防火墙规则或者后端应用的模型上。整体诊断思路按照这套流程走下来基本就清晰了先ping看通断再mtr看路径然后ss看端口最后tcpdump看包。一层一层排除不要一上来就抓包或者一上来就重启服务。实测排障中最忌讳的事就是“用重启解决问题”之后还要假装是配置不当导致的——重启掩盖的是真实故障下一次再爆发只会更难看。2. 进程命令找到谁在吃CPU、屯内存2.1 谁在跑ps 与 top 的正确打开方式进程排查的核心问题永远是三个谁在跑、吃多少资源、能不能动它。ps -ef最常用显示完整命令行配合grep找具体进程ps -ef | grep java但ps输出的是某一瞬间的快照要动态看进程状态靠top。top一进来是交互界面按P按CPU排序按M按内存排序按1看每个核心的负载。这些都是基础操作真正有用的参数是-p指定PID和-H显示线程top -Hp 12345 # 看进程内部每个线程的资源占用这个命令重要在哪Java应用CPU飙高时你看top只能看到一个java进程整体占400%根本不知道是哪个线程在搞事情。加上-H后能看到具体线程TID再用printf %x\n 12346 # 把这个线程ID转成十六进制然后在jstack 12345 | grep nid0x3012里找到对应线程的堆栈就能定位到是哪段代码在跑。这套组合是Java服务排障的基本功我几乎每周都会用到。uptime也有说法它的load average三个数字分别代表1分钟、5分钟、15分钟的平均负载。如果1分钟远大于15分钟说明系统在短时间涌入大量任务持续高要不就是CPU被算满要不就是不可中断的IO等待把进程按住了。但注意load高不一定是CPU问题D状态进程堆积、磁盘IO遇到慢盘都会让load虚高。2.2 处理失控进程kill 家族的讲究找到失控进程后怎么“动手”也有讲究。kill是发信号不是“杀”。最温和的是TERM(15)让进程自己清理退出顽固的就用KILL(9)那是让内核直接回收不给善后机会kill -15 12345 # 优雅退出 kill -9 12345 # 强制结束 pkill -f php artisan queue # 按命令行匹配杀一批pkill -f杀伤面很大匹配的是完整命令行。如果你写pkill -f queue可能把不相关的进程也带走。用过一次教训深刻本想清掉老旧的Python爬虫结果把同事测试队列的脚本全毙了。建议pkill前先pgrep -f预览一下匹配结果确认再动手。还有一种杀不掉的进程叫Zombie僵尸态。它的父进程没有调用wait()回收所以PID还占着。直接kill -9僵尸都没用僵尸不是“活着”是“等着被收尸”只能找到它的父进程让父进程重启或退出才能彻底回收。这个知识点面试和工作里被问到的概率相当高。如果服务器上突然冒出一堆僵尸优先排查它们的父进程是不是有Bug没做异常处理而不是盯着僵尸本体打转。2.3 深入内部strace 与 lsof有时候进程CPU不高、内存也不炸但就是“卡住”不干活。这时候该用strace去跟踪它到底阻塞在哪个系统调用上strace -p 12345 -f -e tracefile,network-p指定PID-f跟随子线程-e限定跟踪哪些类型的系统调用。如果看到程序卡在某个connect或者read上长时间不动那就是在等网络响应或等锁。我看过一次PHP-FPM大量进程阻塞在fsync上一查是磁盘是普通数据盘而非SSD慢IO把所有PHP进程全拖住了替换掉慢盘立刻恢复。lsof用来查看进程打开的句柄特别是排查“进程占用但删不掉的文件”lsof -p 12345 | grep deleted如果发现Java进程打开了很多deleted状态的日志文件那就意味着磁盘空间被写满日志文件被删了但进程没释放句柄空间仍然占着。这是经典的“df看到空间100%但du看不到大文件”的场景。处理方式就是重启这个进程或者让应用重新open日志文件。这个坑我踩过不止一次所以专门把它写进这句命令的备注里。2.4 systemd 时代的进程管理现在的Linux发行版基本都是systemd全家桶。systemctl不仅管服务也是查进程的入口之一systemctl status nginx # 看服务状态、主进程PID、最近日志 systemctl list-units --typeservice --staterunning # 看所有运行中的服务 systemctl restart nginx # 重启服务systemctl status那段输出里最下面几行是journald记录的最近日志很多系统级错误不需要去翻/var/log/就能直接看到。排查开机启动项和异常自启进程时用这两个命令systemctl list-unit-files --typeservice --stateenabled systemctl list-unit-files --typeservice --statefailed热词中反复出现“进程通信IPC”在systemd、nginx、PostgreSQL这些服务里进程间通信方式直接关系着性能表现。排查时可以顺手看一下System V IPC和POSIX共享内存的使用情况ipcs -a # 查看所有共享内存、信号量、消息队列 ipcs -l # 查看大小限制如果一个服务异常崩溃却留下一堆没人释放的信号量或共享内存其他实例启动时会报“资源不可用”。ipcs -s看一眼剩余数量再用ipcrm -s 信号量ID手动清掉。这个场景在跑Oracle和PostgreSQL多实例的机器上不算少见值得记住。3. 磁盘命令从空间告警到IO瓶颈3.1 空间去哪了df 与 du 的区别磁盘告警是最常见的运维工单。df -h看文件系统空间du -h看目录占用大小df -h du -sh /var/log du -sh /data/*df和du的区别要想清楚df是文件系统层面的统计走的是超级块里的元数据du是逐个目录、逐个文件累加的大小。比例失调是常有的事。比如之前说的日志文件被删除但进程没释放句柄df显示/100%du -sh /只显示用了40%中间那60%被deleted文件占着。遇到这种“空间神秘消失”的情况排查方向别瞎猜直接执行lsof L1 | grep deleted找出所有被删除但仍被占用的文件优先看哪几个进程的file对象占用最大对应处理。日常巡检空间增长我固定用两招。第一招是快速定位顶层吃空间的目录du -h --max-depth1 / 2/dev/null | sort -hr | head -20--max-depth1只统计当前目录下一级子目录大小sort -hr按人类可读的数值倒序排一眼看出谁最大。第二招是查超过100M的大文件find / -type f -size 100M -exec ls -lh {} \; 2/dev/null这套组合对日志爆盘、备份文件堆积、临时文件忘清理都有奇效。3.2 inode 耗尽与文件数量飙升还有一类磁盘告警很容易被忽略——df -h明明还有剩余空间但系统就是提示No space left on device。这时要看的不是block是inodedf -iinode是文件系统存储文件元信息的索引节点。如果inode被占满即使磁盘还有几个G也一个文件都建不了。常见元凶是/tmp下垃圾小文件堆了几十万个或者某个程序在循环写缓存但没有清理逻辑。排查和清理find /tmp -type f | wc -l # 统计文件数量 find /tmp -type f -mtime 7 -delete # 删除7天前的文件如果不确定能不能删先find /tmp -type f -mtime 7 | head -50看看文件名再决定是不是安全的临时文件。inode问题一旦发生影响是全局性的连日志都写不进去排错环境特别恶劣所以我对容易产生海量小文件的应用路径会提前做规划比如单独分区、限制inode数量上限、或者用文件系统特性规避占用。3.3 IO 性能分析iostat 与 iotop如果服务本身不算慢但整体吞吐就是上不去很可能是磁盘IO顶到了瓶颈。iostat是分析磁盘IO最实用的统计工具iostat -x 1 5参数含义-x显示扩展统计1 5表示每秒刷新一次共采集5次。重点看%util设备利用率、await平均IO响应时间、r_await/w_await读/写延迟。一台读写正常的SSDawait通常在几毫秒级别如果w_await上百毫秒说明写入链路有严重问题——可能是磁盘降速、RAID重建中、或者劣质虚拟磁盘。%util达到100%并不总代表“坏”可能只是峰值负载瞬时打满。要结合svctm和队列长度看如果队列长时间超过硬盘的queue depth还有大量IO等待那就真的是瓶颈了。只看iostat还不够直观的时候用iotop直接看哪个进程在使劲读写iotop -oP # 只显示有IO操作的进程-o只显示活跃进程-P只显示进程不显示线程。如果看到某个java进程持续在DISK WRITE十几MB/s那你基本可以判断它在疯狂flush数据或写日志顺着这条线索去查程序配置比在应用层猜半天要高效得多。3.4 LVM 扩容与磁盘初始化磁盘用着用着不够用扩分区是运维必修课。如果是KVM/VMware虚拟机先在虚拟化平台给磁盘扩容再在系统里用fdisk扩大分区和pvresize同步LVMfdisk -l /dev/sda # 看当前分区表 pvresize /dev/sda1 # 在线扩大物理卷 lvextend -L 20G /dev/mysql/data # 给逻辑卷加20G xfs_growfs /dev/mysql/data # XFS文件系统在线扩容如果是ext4最后一步换成resize2fs /dev/mysql/data。顺序不能反一定要先扩PV再扩LV再扩文件系统。我试过跳过pvresize直接lvextend直接报Insufficient free space后来才想起来PV没同步白折腾十分钟。论坛里有人问“磁盘必须经过初始化 逻辑磁盘管理器才能访问”其实就是Windows下的磁盘初始化问题对应到Linux就是新加数据盘后要fdisk建分区、mkfs建文件系统、mount挂载。Linux新数据盘上线步骤简单记一下lsblk # 确认新磁盘盘符 fdisk /dev/sdb # n新建分区, p主分区, w保存 mkfs.xfs /dev/sdb1 # 建文件系统 mkdir -p /data mount /dev/sdb1 /data echo /dev/sdb1 /data xfs defaults 0 0 /etc/fstab # 永久挂载/etc/fstab写错会导致开机失败写完最好执行mount -a验证一遍没有报错再重启否则人不在机房的时候服务器挂了就真的只剩远程泪目了。4. 防火墙命令规则、状态与故障定位4.1 firewalld 日常操作现在的CentOS/RHEL系默认用的是firewalld底层封装了iptables。日常放行端口、查状态是最高频操作systemctl status firewalld firewall-cmd --list-all firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload--permanent是写进持久化配置不加这个参数的话重启后规则就没了。条件允许的情况下先用不带--permanent的命令试一阵确认功能正常再永久化reload否则一个失误的持久化规则可能会让远程连接直接断开。放行端口的粒度可以更细一点比如只允许指定来源IP访问firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port port3306 protocoltcp accept这是运维里很实用的写法MySQL、Redis这类内网组件服务限IP访问比裸奔端口安全几个量级。4.2 iptables 规则本质与匹配顺序虽然有firewalld很多老服务或Docker环境仍然直接用iptables。熟悉iptables核心就是表、链、规则三个概念。iptables -L -n -v # 列出所有规则加 -v 看命中次数 iptables -t nat -L -n # 查看NAT规则 iptables -I INPUT 1 -s 10.0.0.5 -j DROP # 在INPUT链最前面插入一条规则的匹配顺序是所有排障的底层逻辑——从头到尾逐条匹配命中即执行不会再往下走。所以在-A INPUT -j REJECT放在最后、拒绝所有之前插入的ACCEPT白名单规则才会生效。这就像排队安检你插队排到第一个后面的人即便是VIP也得等你先过。最典型的坑是加白名单规则时用了-A追加到末尾结果前面的REJECT规则先拦住白名单完全无效。我早期就犯过这个错之后凡是加白名单一律用-I INPUT 规则号插到最前。还有一个隐藏概念要心里有底iptables的nat表有PREROUTING、POSTROUTING和OUTPUT链做端口转发和docker网络隔离全靠它。Docker容器网络不通时很多场景先别急着怀疑容器而是看一眼宿主机NAT规则的映射情况iptables -t nat -nL POSTROUTING如果看到MASQUERADE规则异常或者被清掉容器外联自然就废了。此时大概率是某个软件在重配iptables时把你的规则冲了。4.3 防火墙故障排查实战“用户说服务器访问不了你有三分钟定位问题”。我一般按这套流程来# 第一步看端口监听 ss -lntp | grep 80 # 第二步防火墙是否放行 firewall-cmd --list-all | grep 80 # 第三步iptables完整链路 iptables -L -n --line-numbers如果问题依然在用tcpdump在服务器上抓包tcpdump -i eth0 tcp port 80 -nn看到SYN有进无出马上检查防火墙规则看到SYN和SYN-ACK都正常再查应用日志。思路的顺序永远是“先链路、再端口、再进程、再应用层”而不是一上来就抓包看半天。热词里提到“防火墙黑白名单”firewalld和iptables天然就支持这种策略。黑名单场景是明确从某IP过来的恶意请求直接在INPUT链插入DROP规则iptables -I INPUT -s 203.0.113.99 -j DROP白名单场景则是“只允许公司IP访问SSH”可以先改sshd_config的AllowUsers配合防火墙做双重限制也可以只用防火墙单点实现。按我之前操作的经验落防火墙规则时顺手写注释是极好的习惯iptables -I INPUT -s 203.0.113.99 -j DROP -m comment --comment block scanner 2024-11-02等过段时间想清理规则时iptables -L --line-numbers配合注释能精准找到哪条对应什么。4.4 厂商防火墙与系统防火墙的差别热词里出现“华为防火墙配置命令”“锐捷防火墙配置”这些是硬件防火墙和Linux系统防火墙完全是两个层面的东西。硬防在网络边界Linux防火墙在主机内部两者都要管、都要熟。硬防的配置通常有独立的Web界面和命令行核心概念是安全区域、安全策略、NAT策略生产上一般由网络组负责。如果你刚接手一台服务器且网络不通先确认是不是边界硬防没放行再回来查自己的系统防火墙。很多“明明什么都配好了但连不上”的灵异事件最后都发现是硬防策略的老问题。Linux下的nftables是iptables的现代替代品新系统Ubuntu 22.04/Rocky 9默认已经采用。语法上不一样但排查思路一致nft list ruleset # 查看所有规则 nft add rule inet filter input ip saddr 203.0.113.99 drop # 添加一条阻止规则有iptables基础再上手nftables大概小半天就够了。遇到新系统查防火墙先用nft list ruleset看看全局别惯性用iptables -L发现半天没输出还以为规则被清光了。5. 高频故障排查速查表平时遇到的问题多了我习惯把高频故障整理成一张速查表贴在笔记开头遇到类似现象直接对号入座。这里也分享出来故障现象优先排查命令可能原因与处理方向外网IP能ping通域名ping不通cat /etc/resolv.conf、nslookup baidu.comDNS配置错误检查上游DNS与域名解析记录端口能通但业务超时ss -ant | awk {print $1} | sort | uniq -cTIME_WAIT堆积、连接池耗尽调整内核参数或连接池配置负载很高CPU却不忙top看D状态、iostat -x 1 3IO等待或慢盘拖累定位后替换磁盘或调整IO调度磁盘满了但du查不到大文件lsof L1 | grep deleted删除的文件被进程占用重启进程或让应用重开日志句柄进程杀不掉且状态为Zps -o ppid -p 僵尸PID僵尸进程处理父进程init收养的子进程基本是孤儿应用卡住且top显示正常strace -p PID -f -e tracefile,network阻塞在文件IO、网络等待或锁等待顺着调用栈定位容器外连不上但端口已监听iptables -t nat -nL POSTROUTINGNAT/DNAT规则丢失Docker链被重置重建规则新加规则不生效iptables -L -n --line-numbers规则插入位置不对白名单必须排在拒绝规则之前端口明明开着外面却访问不了firewall-cmd --list-all、tcpdump -i eth0 tcp port 端口系统防火墙未放行或硬防策略拦截按“链路→端口→防火墙”逐层排除这张表是给“半熟悉Linux的人”救急用的核心不是背下来而是理解每条命令背后的排查思路——先看链路、再看端口、然后规则、最后应用。思路比命令重要因为命令会忘思路不会。6. 我的体会与几条补充写到这里这份笔记的主体内容就分享完了。说说我自己在实际操作中的体会。刚接触Linux那几年总喜欢背命令觉得背得多就是厉害。后来踩的坑多了才明白命令只是一个抓手真正值钱的是“在什么场景下用哪条命令、输出代表什么问题、下一步该看什么”。比如本文反复提到的那套排查链连通性差看mtr连接异常看ss想确认真实数据交互用tcpdump每个工具的定位都完全不同互相替代不了。还有一条很重要的经验不要小瞧“自用笔记”的价值。我的这套命令整理从第一次写到现在已经迭代了四五年每次排障遇到新坑就往上补一行注释、一个新命令、一个误操作记录它越来越像一本“踩坑史”。建议你拿到这篇内容后也按照自己的实际环境去跑一遍命令把输出截下来贴到笔记里再补上你自己的业务相关路径和踩坑记录。环境不同细节不同但排障的底层逻辑是通用的。最后分享一个小技巧。排查完一个问题别急着收工花两分钟把“命令 输出 结论”存成一条Markdown记录。这个习惯坚持半年你积累的排障笔记会比任何官方文档都实用而且全是结合你自己业务的场景翻起来效率极高。下次再遇到同一个问题搜索自己的笔记五分钟定位比在群里问同事有效率得多。希望这篇“自用级”笔记也能成为你运维工具箱里顺手的那一把。