可观测性要做到「全链路统一标准」还是「按需分层裁剪」？投入产出账怎么算

背景

社区里最近已经攒了不少可观测性相关的干货：#90 讨论了网络层观测做到什么程度算够，#45 复盘了告警治理把噪音从 57 条压到 6 条的过程，#33 讲 GC 毛刺对 P99 的影响。这些文章共同指向一个问题——观测能力是稳定性体系的底座，但很少有人正面回答：这个底座，建多厚才算"够用"？

我自己在 10 年里带过 3 个不同规模的后端团队，每一次"可观测性建设立项"都撞到了同一堵墙：

• 2018 年那套，5 个服务、3 个工程师，我们直接上了 Jaeger + Prometheus + Loki 三件套，全链路 trace 全量采样。三个月后 trace 集群占了 40% 的存储预算，但真正用 trace 排障的比例不到 20%——大家还是习惯先看 metrics 大盘、再 grep 日志。
• 2021 年那套，30+ 服务、12 个工程师，我们做了"分级"：核心链路 100% trace + 全量 metrics，长尾服务只采 metrics + 抽样 trace（10%）。排障效率反而比 2018 年那次更高，成本降了一半。
• 2024 年那套，100+ 服务，我们尝试 eBPF 零侵入观测 + OpenTelemetry 统一 SDK。SDK 统一这件事本身花了 3 个迭代，业务侧抱怨"加埋点变成加依赖"，最后只推到了 60% 的服务。

常见分歧（我观察到的几种典型立场）

1. 全量统一派：可观测性是"基础设施"，应该像网络一样默认存在。SDK 统一、采样率统一、标签规范统一，否则排障时"这个服务没 trace、那个服务日志格式不一样"的摩擦会持续消耗团队。代表观点：#90 帖里"网络层从基础设施变成故障放大器"就是这个逻辑。
2. 按需裁剪派：可观测性是"投资"，不是"基建"。核心链路全量，长尾服务抽样甚至只保留 metrics。代表观点：存储成本、SDK 维护成本、采样数据对排障的边际收益，三者要做账。
3. 先告警后观测派：在告警信噪比没治理好之前，加再多 trace 也是给值班同学加负担。先把 #45、#39 那套告警治理做完，再谈 trace 深度。
4. eBPF 零侵入派：与其让业务加 SDK，不如从内核/网络层零侵入抓。代价是观测粒度受限于内核事件，且对团队内核功底要求高。

我的倾向与理由

我偏向按需裁剪 + 核心链路全量，理由是落地成本与收益的权衡：

• 全量统一的隐性成本是"SDK 税"：每次升级 SDK 都要回归所有服务，100+ 服务的团队这税不便宜。
• 边际收益递减：trace 从 10% 采样提到 100%，对 P99 排障的提升通常没有 metrics 大盘从"有"到"没有"那么大。真正救命的 20% trace，往往集中在 5–10 条核心链路上。
• 但裁剪有边界：一旦团队里"哪个服务有 trace、哪个没有"变成需要查文档才知道的事，裁剪就退化成了"信息不对称"，这时候应该回头做统一。

想听大家在什么场景下怎么选

具体想请教几个真实场景下的取舍：

1. 团队规模：5 人 / 20 人 / 100+ 人，你的可观测性"最小可用集"分别是什么？有没有一个"低于这个集就不该上线"的底线？
2. 采样策略：核心链路 100% trace，你踩过什么坑（存储爆炸、采样头部偏差、trace 跨服务断链）？
3. SDK 统一 vs 零侵入：OpenTelemetry SDK 推不动的团队，eBPF 路线的落地成本和你们预期差多少？
4. 告警治理与观测深度的先后：#103 讨论帖里"先分级收敛还是先自动化"的争论，是不是也可以套到"先治理告警还是先加深观测"上？
5. 成本账：有没有人算过"100% trace 的存储成本 vs 一次 P99 排障节省的时间"这笔账？数据贴一下大家都参考。

不站队，纯想收集不同规模、不同技术栈下的真实做法。