前端错误上报采样率：固定 10% 采样 vs 全量上报 vs 按错误类型分级采样，你的线上策略是哪个？百万级 PV 下你怎么扛？

【背景】 做了 8 年前端，前 5 年都在 ToB 后台（PV 不大，错误上报基本全量推走就完事），最近 3 年转到 C 端流量型业务。单页核心入口日均 PV 约 1200 万，错误上报走自研 SDK + SLS，SDK 端做了 gzip + 批量 5s 聚合。

去年 Q3 复盘一次线上事故：某次发版后某个 H5 页面出现 JS 运行时错误，但因为采样率固定 10%，实际只有约 1/10 的用户错误被上报，我们 2 小时后才从「错误率突增」的告警里发现——而告警阈值是基于采样后数据配的，真实错误率已经是告警值的 8 倍。更糟的是，采样是随机均匀的，低频但高危的错误（比如支付回调里 0.3% 用户触发的异常）在 10% 采样下几乎必丢。

这件事之后我反复琢磨：前端错误上报的采样策略，社区里到底有没有共识？

【常见的几种做法】 我调研了身边 6 个团队，做法差异很大：

1. 固定低采样率（5%~10%）：最常见的默认配置，理由是「省成本」。SLS 写入费用按 GB 算，百万 PV 下全量上报一天能写几十 GB，运维同学会本能地压采样率。
2. 全量上报：部分小团队（日均 PV < 50 万）直接全量，理由是「错误本来就该 100% 可见」。但流量一大，成本指数上去。
3. 按错误类型分级：JS 运行时错误 / 接口错误 / 资源加载失败 / 白屏 分不同采样率。比如白屏 100%、JS 异常 50%、资源失败 10%。
4. 动态采样：SDK 端根据「当前上报队列压力」或「服务端下发的采样系数」动态调整。某大厂 SDK 我看过源码，是服务端每 30s 下发一次采样系数。
5. 按版本/灰度阶段调整：灰度期间 100%，全量后降回 10%。

【我的倾向与理由】 我现在的方案是 分级 + 灰度感知，具体规则：

• 白屏 / 崩溃类错误：100% 上报，无采样。这类错误低频高危害，丢失一条就等于丢一次事故线索。SDK 端用 navigator.sendBeacon 兜底，确保页面销毁前也能发出去。
• JS 运行时错误：灰度阶段 100%，全量后 50%。理由是 JS 异常通常和版本强相关，灰度阶段样本量小，必须全量才能定位；全量后流量大了，50% 采样下日均仍有 600 万样本，足够做错误聚类。
• 接口错误（HTTP 4xx/5xx）：10% 采样。接口错误量极大（一个 502 风暴能瞬间打出 10 万条），10% 采样已经能还原错误率趋势，且接口侧通常有独立的网关监控兜底。
• 资源加载失败：5% 采样。CDN 抖动时这类错误会爆发，全量上报会冲爆日志通道。

关键一点：告警阈值必须基于「真实错误率」（上报量 / 实际 PV）来配，而不是基于「上报条数」。我们在 SLS 告警里直接算 上报错误数 / 同时段 PV，这样采样率变了告警口径也不用改。

想听大家聊聊的争点：

1. 你的团队用哪种采样策略？分级粒度是 3 级还是 5 级？
2. 动态采样（服务端下发系数）你们试过吗？延迟和实现复杂度值得吗？
3. 低频高危错误（<1% 用户触发）你们靠什么兜底？是 100% 上报、还是走单独的「关键路径全量」通道？
4. 成本压得最狠的你们是怎么算这笔账的——全量上报的日志成本 vs 漏报一次事故的损失，有没有算过具体的数字？

引用一下 @林知远 在热榜里讨论连接池 P99 抖动的思路：「事后复盘不如事前预警」——我觉得前端错误上报的采样策略，本质也是同一道题：采样率就是你的预警灵敏度，设低了就是事后诸葛亮。