基于Prometheus监控Composer镜像源的TCP连接重传率

直接说结论：计算 TCP 重传率，必须用 node_netstat_Tcp_RetransSegs 和 node_netstat_Tcp_OutSegs 这对搭档。千万别指望 node_network_transmit_packets_total 这类网卡计数器——它们只管链路层，根本不知道什么叫“TCP 重传”。

为什么不能用 node_network_* 指标算重传率

node_network_* 系列指标（比如 node_network_transmit_packets_total）统计的是链路层（OSI 第二层）的原始数据包收发，TCP 协议栈的重传逻辑对它来说完全是黑盒。哪怕一个 TCP segment 被重传了 5 次，在网卡眼里也只是 5 个独立的 transmit packet，压根分不清“首次发送”和“重传”。真正能反映重传行为的，只有内核 TCP 协议栈自己维护的那些统计值。

实际踩坑的场景不少：

• 监控面板上重传率常年显示 0，业务日志里却频繁冒出连接超时或 Connection reset by peer。
• 手动用 ss -i 或 netstat -s | grep -i retrans 能看到明显重传，Prometheus 那边却一片空白。
• 有人误把 node_network_receive_errs_total 当作重传指标，结果告警完全跑偏。

一句话：链路层的数据包计数和 TCP 层的重传，根本是两码事。

正确采集重传率所需的 Node Exporter 配置

默认的 node_exporter 其实已经暴露了 node_netstat_Tcp_RetransSegs 和 node_netstat_Tcp_OutSegs，但有三个坑需要确认：

• 启动时千万别加 --no-collector.netstat，否则这两个指标直接消失。
• Linux 内核版本建议 ≥ 3.10，旧内核可能缺失部分 Tcp_* 字段。
• 如果用容器部署，务必保证 node_exporter 容器以 hostNetwork: true 运行，或者正确挂载宿主机的 /proc——否则读不到 /proc/net/snmp 里的 TCP 统计信息。

如何验证？直接访问 http://:9100/metrics，搜索一下看看有没有 node_netstat_Tcp_RetransSegs 这一行。有就放心，没有就回去检查配置。

PromQL 计算重传率的可靠写法

重传率的公式很简单：重传 segment 数 ÷ 总发出 segment 数。但因为原始指标是累计值，必须用速率函数去除累计效应。推荐这样写：

rate(node_netstat_Tcp_RetransSegs[5m]) / rate(node_netstat_Tcp_OutSegs[5m])

这里有几点容易翻车：

• 分母别用 Tcp_InSegs——它包含接收的 ACK、SYN 等控制包，根本不是发送侧的基数。
• 时间窗口建议 ≥ 5 分钟。太短（比如 1 分钟）会因采样抖动产生尖峰假象；太长（比如 30 分钟）又会掩盖瞬时拥塞。
• 计算结果可能大于 1，这并不奇怪——当重传量超过新发量时就会这样，常见于高丢包链路（比如跨境镜像源）。此时应该触发告警。
• 如果某个节点没有数据，先检查 node_netstat_Tcp_OutSegs 是否为 0 —— 空闲节点没有 TCP 发送，分母为 0 会导致除零错误。

监控 Composer 镜像源时的特殊处理

Composer 镜像源（比如 packagist.org 或私有镜像）本质上就是 HTTP(S) 请求，重传率高往往指向网络路径问题，而不是应用层本身。排查建议：

• 对比不同镜像源的重传率：国内镜像（阿里云、腾讯云等）和 packagist.org 官方源分别测一下，看是不是地域性问题。
• 结合 probe_success{job="blackbox", target="https://repo.packagist.org"} 判断连通性是否稳定。
• 盯住 rate(node_netstat_Tcp_RetransSegs[5m]) 的绝对值：持续超过 100/s，基本可以断定物理链路或中间设备（防火墙、运营商路由）有问题。
• 别对单次 composer install 命令做实时重传监控——它的 TCP 连接生命周期太短，指标聚合粒度不够。正确做法是关注宿主机整体出口网卡的趋势。

最后提醒一句：重传率本身只告诉你“出事了”，但它不告诉你丢包具体发生在哪里。它只是第一个红灯，下一步必须配合 mtr 或 tcptrace 定位具体跳点，否则永远在猜谜。