网络可观测性做到什么程度算够：全链路跟踪还是告警兜底就收手？

背景：做了 8 年网络工程，最近一年越来越频繁地遇到"应用侧说接口抖了，但抓包看 TCP 层一切正常"的扯皮现场。我自己的判断是：分布式系统里，网络这一层从"基础设施"变成了"故障放大器"，而大多数团队的观测手段还停留在"ping 通了就算活着"。

常见分歧（我听到的三种做法）：

1. 告警派：只关注丢包率、RTT、带宽水位，配上阈值告警，认为网络是黑盒，能跑就行，观测成本要花在业务指标上。
2. 全链路派：每一跳都打点，跨机房 RTT、重传、拥塞队列、DNS 解析时间全采，配 eBPF 抓内核态，追求"任何抖动都能定位到具体哪一跳"。
3. 折中派：核心路径（网关→LB→关键服务）做细粒度观测，边缘链路只保留基础指标，按业务重要性分级。

我的倾向与理由：我站在折中派，但比多数人更激进——我会把"网络观测预算"当成一个明确的成本项来算：一套 eBPF + Prometheus + 时序库，对一个 20 节点集群，硬件和运维人力大概每月 X 元级别（这里不写具体数字，各家不同）。这笔钱换来的收益是：下次 P99 抖动，你能在 10 分钟内回答"是网络、是下游、还是我自己"，而不是花两天互相甩锅。我的经验是：观测的 ROI 不是故障发生时算的，而是排障时间从"天"降到"小时"那一刻算的。但我也承认，对 5 个节点以下的小集群，全链路观测大概率是过度设计——ping + 关键接口 RTT 就够。

想听大家聊聊：

• 你们团队现在网络侧到底采了哪些指标？最让你后悔没采的是哪个？
• 跨机房 / 跨云场景下，你怎么判断"慢"是网络问题还是应用问题？有没有一个你愿意赌底裤的判据？
• 你觉得 eBPF 这类内核态观测，在生产环境是"该上的标配"还是"高风险玩具"？
• 小团队（<10 节点）和中型团队（20–100 节点），观测策略应该有什么本质区别？

欢迎贴你踩过的坑，具体场景越细越好，空谈"要重视可观测性"的咱们楼下接着聊。