「内核 tcpi_rtt 全程平稳、应用 P99 却尖峰」：用 socket 级 tcp_info 做提前预警，到底该盯哪几个字段、阈值怎么定？

背景

8 年网络工程，现保一个跨机房调用链（HTTP/1.1 长连接池，单侧峰值约 800 conn/s、存量长连接 2 万，内核 5.10，节点 40 台）。过去 12 个月复盘过 4 次「P99 抖动」事故：应用侧 P99 从稳态 ~80ms 跳到 600ms~1.2s，持续 10~40s 后自愈；但同期 ss -ti / bpftrace 采的 socket 级 tcpi_rtt 全程稳定在 1.1~1.4ms，重传率 0.02% 以下，tcpi_rttvar 没明显抬升——内核视角的 RTT 完全没动，尖峰只出现在应用层。

现象

• 应用 P99 尖峰时，tcpi_rtt 纹丝不动（说明 RTT 尖峰不是"路径 RTT 变长"，更像对端排队/处理慢或本地接收窗口/缓冲侧的阻塞）；
• 抓包看 SYN-ACK / ACK 的 RTT 也正常（与站内 #896 那次「抓包 RTT 正常但应用超时」很像）；
• 内核 RTT 稳定 + 重传低 → 现有的「重传率告警」「RTT 告警」两条规则全部漏报；
• 事后只能靠应用 5xx / P99 曲线反推，没有提前量。

已尝试的排查与结果

1. 节点级 nstat / netstat 聚合：重传 0.02%、无 RST，看不出异常；
2. socket 级 tcpi_rtt / tcpi_rttvar（bpftrace kprobe 采）：尖峰时段平稳，没用；
3. 应用层 APM 的 P99：事后能看到，但滞后于事故起点 10~30s；
4. 参考了 #584（bufferbloat：队列把 RTT 从 5ms 灌到 480ms）与 #702（rwnd < BDP 压吞吐）：但这两篇都是"内核 RTT 会变"的场景，我这次是内核 RTT 不变、应用 RTT 变，现有经验对不上。

期望得到的答案形态

1. 在「内核 RTT 平稳 + 重传低」的前提下，socket 级 tcp_info 里哪些字段在尖峰窗口确实会动（如 tcpi_snd_cwnd、tcpi_rcv_ssthresh、tcpi_snd_wnd、tcpi_unacked、tcpi_pacing_rate，或需要额外看 sk_rmem_alloc / sk_backlog），最好带一个真实观测到的数值区间；
2. 你们线上实际落地的告警规则：字段 + 阈值 + 窗口（比如「同一 pool 内 >N% 连接的 cwnd 在 T 秒内收缩到 <X」），以及这条规则相比应用 P99 的真实提前量（秒级或分钟级，要数字）；
3. 如果 tcp_info 也抓不住，你们是怎么补的（eBPF socket map 看 sk_drops / sk_rmem_alloc？对端侧指标？网络金丝雀？），给一个可复现的最小观测集。

欢迎贴真实数据（脱敏即可），有 3 个字段 + 2 个阈值 + 1 个提前量数字就能帮我收口。