前端线上数据上报，采样还是全量？聊聊成本与信号的权衡

背景

做了 15 年前端，这两年越来越觉得：前端可观测性最大的坑，不是「没监控」，而是「监控上了，但要么贵到没人敢全开，要么采样开到关键信号全丢了」。我最近在给一个日活千万级的 C 端 H5 重构上报链路，正好把这个问题逼到桌面上了：错误日志、Web Vitals、长任务、资源加载、自定义业务事件，每一类都面临同一个选择——100% 全量上报，还是采样 N%？ 这背后是 SDK 体积、上报流量、存储与查询成本，和「能不能在凌晨 3 点定位到那个只出现 17 次的白屏」之间的硬权衡。

常见分歧 / 几种做法

我观察下来团队里大概三种流派：

1. 全量派：「错误就 100%，性能也 100%，别采样，采样会漏掉长尾。」代价是存储和查询费用线性上涨，热门页面一条错误日志一天能堆到几个 GB。
2. 一刀切采样派：所有事件统一 10%~10% 采样，简单省事。代价是稀有错误（只影响 0.1% 用户的机型/浏览器）大概率被采样掉，等发现时已经烧了几天。
3. 分类分级派：错误 100%、Web Vitals 采样、资源加载按阈值、业务事件按重要性分级，用「优先级 + 去重 + 限流」组合。最贴近收益，但工程复杂度最高，SDK 和后端都要改。

还有第四个常被忽略的变量：用 SaaS（Sentry / Datadog / 云厂商 APM）还是自建采集链路。SaaS 省心但按事件计费，全量上报的账单会先吓退你；自建可控但维护成本自己扛。

我的倾向与理由

我倾向「分类分级 + 去重合并 + 客户端限流」，理由有三：

• 错误是「低频高价值」，采样会直接丢掉长尾，所以错误类必须 100% 但要在服务端按 errorKey 去重聚合（同一 stack + 同一版本只算一条新信号），把存储成本压下来，而不是靠丢数据来省钱；
• Web Vitals 是「高频低价值」，单条意义小，采样 + 分位数（P75/P95）上报足够，配合 RUM 的 navigator.connection 区分网络环境；
• 真正决定成本的不是「采不采样」，而是有没有在客户端做去重和限流——同一个用户 10 分钟内重复报错 3 次，上报 1 次就够。

一句话：省钱的正确姿势是「聚合去重」，而不是「随机丢弃」。

想听大家

想听听各位在什么场景下怎么选：

• 你的错误日志是 100% 还是采样？稀有错误的长尾你们怎么兜底（比如保留 100% 但只存最近 N 天）？
• 用 SaaS 还是自建？被账单逼退过吗，怎么把成本控住的？
• 客户端去重/限流你们做到什么粒度（按 errorKey？按用户？按时间窗）？
• 有没有「采样省下的钱」和「漏掉的故障」之间算过 ROI 的真实案例？

欢迎贴你们的具体数字（日均事件量、存储成本、错误率量级），越具体越好讨论。