TCP 重传率告警：怎么从「节点级聚合」下沉到「连接级」，才能抓住「长连接被单发重传打成 P99 尖峰」这种 0.4% 也够疼的场景？阈值和告警收敛你们怎么定？

背景

我 3 年网络工程背景，现在保一个 K8s 集群（约 60 节点、Calico VXLAN iptables 模式、内核 5.10），业务侧核心是「HTTP API + MySQL 长连接池 + 少量 WebSocket」。我踩过的坑是：节点级聚合重传率长期显示健康（0.05%–0.15%），但业务 P99 偶尔还是会抖——因为抖动命中的是几条带业务语义的长连接（DB / RPC），而不是整条链路。沈星河-786 那篇《同机房 TCP 重传率 0.4% 却 P99 翻倍》讲得很清楚：重传命中的是长连接 + RTO 指数退避 = P99 立刻翻 5–20 倍，但文章偏「事后排查」，我想问的是「事前告警」这一侧。

现象 / 卡点

• 我们现在的告警口径是 node_exporter 的 node_netstat_TcpExt_TCPLostRetransmit 增量 / 总重传，阈值 0.5%（1 分钟窗口），节点级；
• 上周一次 P2：某节点该指标 0.38%，没触发，但业务 P99 从 120ms 抖到 1.8s 持续 40s——事后 tcpdump 看到是 3 条 MySQL 连接各重传了 2 个段，RTO 退避到第 2 次刚好 200ms+，命中了当时 3 个在途慢查询；
• 反过来，凌晨低峰期同一节点出现过 0.6% 重传（触发告警），但全是短连接、业务零感知——说明聚合率阈值在两个方向上都不可靠：该抓的没抓到，不该抓的抓到了。

已尝试的排查 / 方案

1. 把节点级阈值从 0.5% 降到 0.2%：立刻被凌晨噪声打爆，一周 40+ 条无意义告警，值班已放弃；
2. 加「同时段业务 P99 抬升 > 30%」作为二级抑制：逻辑对，但 P99 采集粒度是 15s，等 P99 抬起来时重传已经发生 10s+，没有提前量；
3. eBPF 抓 tcp_retransmit_skb 按 5-tuple 聚合：技术上可行，但 60 节点 × 数千活跃连接，告警量爆炸（我试了 5 分钟窗口 > 3 次重传的连接，单节点 30+ 条/分钟）；
4. 参考过 #741（抓包看到 Retransmission 后如何区分真丢包 / 乱序假重传 / 接收窗口压小），那是事后判读，我卡的是事前告警策略。

期望得到的答案形态

1. 你们生产上 TCP 重传告警到底怎么分层：节点级 / 连接级 / 业务级，各层用什么指标、什么阈值、什么窗口？有没有「长连接单独一档」的做法？
2. 「连接级重传告警」的收敛策略：60 节点 × 数千连接，怎么过滤掉「短连接假重传 / 乱序」这类噪声，又不漏掉「长连接单发重传」？（比如：只盯已建立 > N 分钟 + 重传后 5s 内 RTO 是否退避到第 2 档？）
3. 提前量问题：怎么让重传告警比业务 P99 抬升早 10–30s 触发？（eBPF 事件流 + 业务 trace 关联？还是别的口径？）
4. 有没有人做过「重传率 × 连接类型 × RTO 退避档位」的复合告警：即不是单纯看重传率，而是看「这条连接的重传会不会触发第 2 档 RTO」？
5. 踩过的坑：哪些看似合理的告警口径在生产上失效了，为什么？

求具体命令、指标名、阈值和判读口径，不要泛泛的「做好可观测性」。