全量探测 vs 最小探针集：50 节点集群做「应用级 pingmesh」，探测矩阵怎么缩到 CPU 预算 0.5% 内还不丢 P99 毛刺信号？

背景

5 年网络工程，负责一个 50 节点（双口 25G、内核 5.10）的跨机房业务集群。过去半年复盘过 3 次「P99 从 30ms 抖到 200ms+，持续 10~60s 自愈」的事故，事后抓包 / 看 nstat 都能找到证据（retrans、零窗、个别 NIC 队列积压），但事前没有任何信号——现有监控只有 ping + 丢包率，粒度太粗，等应用侧 5xx 报警时链路已经恢复了。

现象

想引入应用层 pingmesh（每节点对若干 peer 周期性发小包，记录 RTT / 超时），把「网络毛刺」提前 30s 级别抓住。但 50 节点全量双向就是 2450 条边，按 1s 间隔、200ms 超时的预算，粗算 CPU 开销 3~5% 起步（还没算日志和存储），业务方明确说不接受这个成本。

已尝试的排查与结果

1. 用 node_exporter 的 NIC 指标 + nstat 的 retrans / zero_window，做了 2 周观测——retrans 确实领先于应用侧 P99，但它是「事后确认」，等 retrans 起来时用户已经感知了；
2. 试了每节点只探测 3 个 peer（固定邻居），跑了 1 周——信号太稀疏，3 次事故里只捕获到 1 次，漏掉的 2 次恰好发生在「非邻居方向」；
3. 想上 eBPF 被动采集（socket-level RTT），但 #1526 那位的经验是探针选不好就白做，而 #1701 问的是探针参数怎么定，都没直接回答「主动探测的矩阵规模怎么砍」。

期望得到的答案形态

不是「上 pingmesh」这种结论，而是希望有人给出可复现的缩矩阵方案，越具体越好：

• 采样策略：是随机 peer、按 AZ / 机架分层、还是按历史 RTT 方差加权？给出具体的选择逻辑；
• 参数预算：间隔 / 包大小 / 超时 / 采样比，给一组你们线上跑过的数字（哪怕是「我们 200 节点用 XX 配置，CPU 实测 0.X%」这种量级）；
• 判据：探测 RTT 的哪个分位（P50/P95/P99）+ 多长窗口，能比应用侧 5xx 提前 ≥30s 报警，误报率大概多少；
• 兜底：如果主动探测预算实在压不下来，被动 eBPF 采集的「最小指标集」能不能替代？边界在哪？

欢迎带你们线上跑过的具体配置和实测数据来答，不需要理论最优，要「能落地、算得清成本」的方案。