linux tcp连接性能分析需采集/proc/net/snmp等内核指标，聚焦建连、维持、释放、异常四阶段瓶颈，通过node exporter+prometheus+grafana实现时序监控与闭环调优。
Linux TCP 连接性能指标的采集与可视化分析，核心在于把内核暴露的连接状态、错误统计和协议栈行为转化为可抓取、可聚合、可下钻的时序数据，并在 Grafana 中构建面向业务影响的视图。关键不是堆指标，而是聚焦连接生命周期中的瓶颈点：建连是否卡顿、维持是否稳定、释放是否及时、异常是否高频。
采集哪些 TCP 关键指标
这些指标直接反映连接健康度，全部来自 /proc/net/snmp 和 /proc/net/netstat，Node Exporter 默认启用 --collector.netstat 即可采集：
-
活跃连接数：
node_netstat_Tcp_CurrEstab—— 当前 ESTABLISHED 状态连接数，是容量水位的核心参考 -
新建连接速率：
node_netstat_Tcp_InSegs减去node_netstat_Tcp_OutSegs的差值趋势（需导出为 rate）—— 判断突发流量或爬虫冲击 -
连接异常指标：
node_netstat_Tcp_RetransSegs（重传段）、node_netstat_Tcp_EstabResets（异常关闭）、node_netstat_Tcp_AttemptFails（建连失败）—— 定位网络丢包、服务拒绝或客户端异常 -
半连接队列压力：
node_netstat_TcpExt_ListenOverflows和node_netstat_TcpExt_ListenDrops—— 指示syn queue溢出，常伴随tcp_max_syn_backlog不足或 SYN Flood
确保采集配置有效
光开 collector 不够，必须验证数据真实可用：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 访问 Node Exporter 的
/metrics页面（如http://192.168.1.10:9100/metrics），搜索Tcp_CurrEstab或Tcp_RetransSegs，确认有非零数值返回 - Prometheus 抓取间隔设为
15s—— 太短会压垮/proc/net/接口；太长（如 60s）会漏掉短时连接风暴或瞬时重传尖峰 - 在 Prometheus 中用
rate(node_netstat_Tcp_RetransSegs[5m])计算每秒重传段数，比原始计数更有意义
Grafana 可视化建议
避免堆砌仪表盘，优先构建三类视图：
-
连接健康看板：并列显示
CurrEstab（绝对值）、rate(Tcp_InSegs[1m])（建连速率）、rate(Tcp_RetransSegs[1m])（重传率），加一条rate(Tcp_EstabResets[1m]) / rate(Tcp_CurrEstab[1m])计算异常断连占比 -
建连失败归因图：用堆叠柱状图展示
TcpAttemptFails（SYN 超时）、TcpExtListenDrops（半连接丢弃）、TcpExtSynRetrans（SYN 重传）三者占比，快速区分是客户端问题、网络丢包还是服务端队列瓶颈 -
连接生命周期热力图：用 Prometheus 的
histogram_quantile+ Node Exporter 的node_netstat_TcpExt_SynTime（如有启用 ethtool collector）或自定义 exporter 补充的连接建立耗时直方图，观察 P90/P99 建连延迟是否突增
结合内核参数做闭环分析
指标异常时，不能只看数字，要联动检查对应调优项：
- 若
ListenOverflows > 0持续出现，检查net.ipv4.tcp_max_syn_backlog和net.core.somaxconn是否足够，同时确认应用 listen() 的backlog参数未被低估 - 若重传率高但
ListenDrops = 0，重点查net.ipv4.tcp_rmem是否过小导致接收窗口收缩，或是否存在中间设备限速/丢包 - 若
CurrEstab长期高位不降，配合ss -s输出验证是否存在 TIME_WAIT 泛滥，再检查net.ipv4.tcp_tw_reuse和net.ipv4.tcp_fin_timeout设置
