前端错误监控的"采样率"到底怎么定：全量 0 漏报 vs 采样漏报 3%，你的取舍标准是什么？

背景

我做了 5 年前端，从 SaaS B 端（月 UV 50 万）做到 C 端（月 UV 500 万），错误监控一路踩坑。最痛的一次：某支付回调页面报错，Sentry 默认 100% 上报但被我们「按项目」限流到了 5%，结果一个「银行侧签名校验失败」的错误 2 天才被聚合出来，用户侧已经投诉了 40 多单。事后复盘：这个错误在 500 万 UV 下日均只有 800 次，采样 5% 后日均 40 次，被埋在其他高频错误里根本看不出来。

从那以后我开始纠结一个事：采样率到底该由谁定、按什么标准定。今天想抛出来跟大家聊聊。

我见到的四种做法（也是常见的分歧）

1. 全量派：错误必须 0 漏报，尤其金融 / 支付 / 医疗场景。代价是 Sentry 账单从 8 千/月涨到 8 万/月（500 万 UV 全量上报 + 完整 stack），带宽和存储都是硬成本。
2. 固定采样派：统一 1% 或 0.1% 采样，统计学上 P99 置信区间够用，成本可控。代价是低频但关键（如支付回调）的错误直接被漏掉，上面我踩的坑就是这类。
3. 分级派：给错误打标签，critical（登录/支付/下单）全量，warning（表单校验、埋点异常）1% 采样，debug 1‰。SDK 本地做 5 分钟窗口去重，同一页面同一错误只上报一次。
4. 动态阈值派：按错误率实时调采样，>1% 错误率时全量，<0.01% 时 1%，中间线性插值。实现复杂，需要后端聚合反馈给前端。

我的倾向 + 理由

我倾向 分级 + 本地去重，理由有三：

• 成本可控：500 万 UV 实测，分级后 Sentry 月账单从 8 万降到 6 千（降幅 92.5%），漏报率 < 0.3%（只漏 debug 级）。
• 关键路径 0 漏报：给支付回调、登录、下单三个入口打 critical 标签，SDK 里判断 location.pathname 命中白名单就绕过采样，这部分错误一条不丢。
• 本地去重窗口 5 分钟：同一 SPA 路由 + 同一错误指纹 + 5 分钟内，只上报一次 + 一次聚合计数，能把 90% 的「F5 风暴」和「用户疯狂刷新」压掉。

具体可复现的配置（Sentry SDK v7）：

Sentry.init({
  dsn,
  // 默认 1% 采样
  sampleRate: 0.01,
  beforeSend(event, hint) {
    // 关键路径全量
    const criticalPaths = ['/pay/callback', '/login', '/order/submit'];
    if (criticalPaths.some(p => location.pathname.includes(p))) {
      event.sampled = true; // 强制上报
      return event;
    }
    // critical 标签全量
    if (event.tags?.level === 'critical') {
      event.sampled = true;
      return event;
    }
    return event; // 走默认 1% 采样
  },
  // 本地去重：5 分钟窗口
  integrations: [
    new Sentry.Integrations.Dedupe({ maxFrames: 20 }),
  ],
});

但我也承认这套有盲区：跨页面的低频错误（用户 A 报错、用户 B 不报）去重窗口压不住，只能靠 critical 标签兜底。

想听大家怎么选

1. 什么场景下你会坚持全量？是金融合规要求，还是真的踩过采样漏报的坑？
2. 采样率定多少你觉得「够用」？1% 还是 0.1%？依据是什么（统计学置信度？账单？）
3. 本地去重窗口你们设多长？5 分钟还是 30 分钟？有没有被「F5 风暴」坑过的？
4. 动态阈值派有没有人真落地过？实现复杂度如何，后端聚合反馈链路怎么搭？

欢迎贴你们的账单数据 + 漏报率实测，数字比观点有用。