前端 RUM 的「全采 vs 采样」之争：100% 上报的 CDN 成本你算过吗？但采样漏掉的那条 P0 你背过吗？

【背景】

做了 10 年前端，最近半年把团队的前端可观测性链路（RUM + 错误上报 + 性能指标）重新梳理了一遍。最纠结的一件事是采样率到底怎么定。

我们的量级：核心页面 DAU 约 80w，日均 PV 约 400w，走的是自研上报 SDK → 边缘网关 → Kafka → ClickHouse 的链路。

现状是「error 级别全采、warning 采 20%、info/perf 采 5%」。看着挺合理，但上个月一次 P0——某个低版本 iOS 上白屏，全量影响约 1200 用户——因为白屏走的是「页面加载成功但内容渲染为空」，被归到了 info 级别的 perf 事件，5% 采样只捞到 60 多条记录，且分散在不同机型上，排查花了 3 小时才定位到是某次发版把 hydration 的 Suspense fallback 吞了。

60 条记录里真正有用的可能就 3 条。

【常见分歧（我见过的四种做法）】

1. 全采派：前端错误是「低频高价值」事件，采不到就是漏了。流量再大也得全采。

   • 代价：80w DAU × 人均 6 次页面 × 每次 2~4 个上报事件 ≈ 日均 1000w+ 条，CDN + ingestion 成本一个月大概 1.5w~2w（我们内部结算价），而且 Kafka 分区压力在早高峰非常明显。

2. 采样派：按固定比例采（10% 或 1%），成本可控，统计意义上够用了。

   • 代价：P0 级别的低频次错误（影响 1000 人以下的）大概率只采到个位数，复现和定位都靠猜。

3. 分级派（我们现在的做法）：error 100%、warning 20%、info 5%。

   • 代价：分级标准本身是「拍脑袋」的——白屏算 error 还是 info？接口 500 算 error 还是 warning？不同团队口径不一致，SDK 里 level 字段被业务代码随意赋值的不少。

4. 动态派：正常采 10%，告警触发后自动升到 100%，事后回落。

   • 代价：「告警触发」本身依赖后端 metric 或用户反馈，前端 RUM 的告警往往滞后于后端（因为前端才是用户侧的第一现场）；而且「自动升采」的窗口期内的数据，你采到了但后端分析管道还没扩，可能直接丢掉。

【我的倾向与理由】

我倾向**「关键路径全采 + 非关键路径采样 + 采样率本身可观测」**，具体拆成三层：

• 第一层（全采，不可采样）：JS 异常（uncaught error + Promise rejection）、白屏/骨架屏超时、关键 API 失败（不是所有 API，是「页面核心功能依赖的那 3~5 个」）。这一层事件量其实很小——正常状态下一天也就几千条，全采成本可以忽略。
• 第二层（高比例采样，50%~100%）：性能指标（LCP / INP / CLS）、路由切换耗时、资源加载失败。这些量级大，但统计意义更重要，50% 采样在 80w DAU 下样本量已经足够画分布。
• 第三层（低比例采样，5%~10%）：埋点行为事件、非关键 API 响应、调试日志。

关键的一点：采样率本身要进 metric。每次上报都带 sample_rate 字段，ClickHouse 里做加权还原；同时把「当前采样率」作为一个 metric 暴露到监控面板，采样率变了你能第一时间看到。

落地成本：SDK 改造约 3 人日，后端 ingestion 加一个 sample_rate 字段约 0.5 人日，ClickHouse 查询模板改加权约 1 人日。总共不到 1 周，比「P0 排查时多花 3 小时」的隐性成本低得多。

【想听大家】

1. 你们线上前端 RUM 的采样策略是什么？流量多大开始觉得全采扛不住的？
2. 「白屏」到底应该算 error 还是 perf/info？你们的 SDK 里有没有强制约定？
3. 有没有人做过前端的「tail-based sampling」——不是按固定比例，而是按「页面 + 设备 + 网络条件 + 错误类型」的组合动态调采样率？效果怎么样？
4. 后端 trace（OpenTelemetry）和前端 RUM 的 session/trace 关联，你们怎么做的？W3C traceparent 透传到前端 SDK 这一步，落地成本到底有多大？
5. 最后一个：你们团队里，前端 RUM 的数据到底谁在消费？是前端自己看、SRE 看、还是 PM 看？如果没人消费，采样率是不是其实无所谓？