eBPF 抓 TCP 重传做生产告警：80 节点 K8s 集群里从探针部署到 SLO 闭环，你们踩过哪些坑？

【背景】 5 年网络工程经验，最近接手一个 K8s 集群（v1.26，80 节点、约 1200 Pod）的网络质量监控。痛点很明确：应用侧反复报"接口偶发超时"（P99 从 200ms 跳到 1.2s，持续 3~5s 后自愈），但现有被动监控（Prometheus + node_exporter）只能看到网卡计数器（rx/tx errors、dropped），完全无法区分是 TCP 重传、SYN 被 drop、还是内核 socket 缓冲区溢出导致的。每次排查只能登节点 tcpdump，不可持续。

【已尝试与结果】

1. node_exporter + SNMP：粒度太粗，只有接口级累计值，无法按 Pod / 五元组切分；
2. tcpdump 抓关键节点：单节点 demo 能复现（看到大量 RST + 重传），但 80 节点 7×24 跑不现实，且 pcap 文件太大，没法做告警；
3. 用 bpftrace 写了个 tcp_retransmit 探针，单节点能出数据（每秒打印重传计数），但离生产还差很远：
   • 80 节点怎么部署？DaemonSet 带 bpftrace 镜像？还是编译成静态二进制？
   • 探针本身的 CPU / 内存开销你们实测过多少？（担心高负载节点上 eBPF 本身成为瓶颈）
   • 指标怎么导出？我想到的是 Prometheus textfile collector 或自定义 exporter，有没有更轻量的方式？
   • 告警阈值怎么定？"5s 窗口内重传率 > 0.1%" 还是 "连续 3 个窗口 > 0.05%"？有没有人给过真实跑出来的分布数据？
   • 怎么关联到具体 Pod 对（src pod IP:port → dst pod IP:port）？需要解析 /proc/net 还是靠 eBPF 里直接读 sock 结构？

【期望得到的答案形态】

• 生产环境 eBPF 探针的部署模式（DaemonSet / sidecar / 独立 DaemonSet + 静态二进制），以及你们实测的资源开销（CPU %、内存 MB）；
• 指标导出与 Prometheus 对接的具体做法（exporter 代码结构或配置片段）；
• 告警阈值的设定依据（最好有真实分布数据或 P99/P999 截图描述）；
• 如何把重传事件关联到具体 Pod 对（五元组），以及你们 Grafana 面板的布局思路；
• 踩过的坑：比如内核版本兼容、cgroup v1 vs v2、节点重启后探针恢复等。

不用给完美方案，能分享你实际跑通的链路 + 关键配置就行。