Linux网络排查指南:手把手教你监控TCP连接状态
大家好,我是33blog的运维老司机。今天想和大家分享一个我在排查线上网络问题时常用的技巧 – TCP连接状态监控。记得去年双十一大促时,我们服务器突然出现大量TIME_WAIT连接,差点导致服务不可用,就是靠这些方法快速定位问题的。
为什么需要监控TCP连接?
在Linux系统中,TCP连接的状态变化就像一部精彩的悬疑剧。从三次握手的SYN_SENT,到正常通信的ESTABLISHED,再到分手的FIN_WAIT、TIME_WAIT…每个状态都藏着重要的线索。
我经常遇到这样的场景:服务器负载突然升高,但CPU、内存看起来都正常;或者某些API响应变慢,但代码逻辑没问题。这时候,TCP连接状态往往能给出关键提示。
基础命令:netstat和ss
先介绍两个老伙计,netstat和ss。虽然现在更推荐使用ss,但netstat在某些老系统上还是很有用的。
# 查看所有TCP连接状态统计
netstat -ant | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
# 更现代的替代方案
ss -ant | awk 'NR>1 {++S[$1]} END {for(a in S) print a, S[a]}'
小技巧:我习惯把这两个命令做成alias放在.bashrc里,比如:
alias tcpstat='ss -ant | awk '"'"'NR>1 {++S[$1]} END {for(a in S) print a, S[a]}'"'"''
进阶工具:/proc/net/tcp
当需要更详细的信息时,我会直接查看/proc/net/tcp这个神奇的文件。它包含了内核级别的TCP连接信息,格式虽然原始但信息量巨大。
# 查看前10条TCP连接信息
head -10 /proc/net/tcp
这里有个坑要注意:状态码是十六进制的!比如0x0A表示LISTEN,0x01表示ESTABLISHED。我刚开始用的时候经常搞混,后来专门做了个对照表贴在工位上。
实战案例:TIME_WAIT风暴
去年我们遇到一个典型问题:某台服务器突然出现大量TIME_WAIT连接,导致无法建立新连接。我是这样排查的:
- 先用ss -s查看汇总统计,确认TIME_WAIT数量异常
- 然后用ss -tan state time-wait | wc -l确认具体数量
- 最后通过ss -tan state time-wait dst 目标IP定位到问题服务
解决方案是调整了内核参数,增加了TIME_WAIT回收速度:
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
可视化监控方案
对于长期监控,我推荐使用Prometheus+Granfa的方案。node_exporter本身就提供了TCP状态的metrics,配置起来很简单:
# prometheus.yml配置示例
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
然后在Grafana中导入Node Exporter的Dashboard,就能看到漂亮的TCP状态图表了。
写在最后
TCP连接监控看似简单,但真正用好了能解决大问题。建议新手可以从ss命令开始练习,慢慢再接触更底层的工具。遇到问题时,记住我的排查三部曲:看状态统计 → 定位异常状态 → 分析具体连接。
如果你在实践过程中遇到什么问题,欢迎在评论区留言讨论。下次我会分享更深入的TCP调优经验,包括如何优化keepalive参数等实战技巧。
运维老司机果然干货满满,这个TCP状态监控的方法太实用了!
学到了,TIME_WAIT这个坑我也踩过,当时排查了好久
想问下作者,现在新系统是不是都用ss替代netstat了?
去年双十一我们也是被TIME_WAIT搞惨了,早点看到这篇文章就好了😭
感谢分享!已经收藏,下次服务器出问题就按这个套路来
“TCP连接的状态变化就像一部精彩的悬疑剧”这个比喻太形象了