【背景】 3 年前端，现在负责一个中型 B 端产品：日均 80w PV，12 个核心页面，React + Webpack，自研监控 SDK 上报到自建的日志平台。
去年花了一个季度把可观测性「补齐」：
- Sentry：JS 异常 + 接口 4xx/5xx 错误（全量上报）
- 自研 RUM：LCP / FCP / INP / CLS / TTFB（全量上报，按页面 + 浏览器 + 地域 + 网络类型四个维度聚合）
- Grafana 大盘：3 个 dashboard，覆盖错误率、性能分位、资源加载瀑布
- 告警规则：5 条（JS 异常率 > 0.5%、接口 5xx > 2%、LCP P75 > 4s、FCP P75 > 2s、CLS > 0.2）
结果用数据说话：
- 过去 6 个月，5 条告警一共响了 34 次，其中真正定位到线上问题的只有 7 次（误报率 ~79%）
- RUM 原始数据每月约 38GB，存储 + 计算成本约 2000 元/月
- 团队 4 个前端，真正每周看一次大盘的只有 1 个人（就是我）
- 最痛的一次：LCP 告警响了 3 次，排查后发现是 2 次 CDN 回源抖动（5 分钟自愈）+ 1 次某运营商 DNS 劫持（跟前端无关）
今年我重新审视这套东西，核心问题是：可观测性的 ROI 到底怎么算？ 不是「有没有」，而是「花了多少钱、覆盖了多少真实风险、团队是否真的在用」。
【常见分歧 / 几种做法】
做法 A：三件套必须齐（"缺一个就是盲区"） RUM 看用户体感、Sentry 看代码异常、接口监控看服务端链路，三者互补。B 端产品虽然用户容忍度高，但"白屏 + 接口慢 + JS 报错"是三种完全不同的故障模式，缺任何一个都可能漏掉真实事故。
做法 B：够用就行（"Sentry + 一条 5xx 告警"） B 端产品用户不是 C 端那种"3 秒没加载就走"的场景。JS 异常有 Sentry 兜底，接口 5xx 有网关日志，LCP/FCP 这些指标存着好看但没人基于它做决策。把 RUM 采样率降到 1%、告警只留 1-2 条最核心的，省下的存储和人力成本去做业务迭代，ROI 更高。
做法 C：按页面分级（"核心页面全量，长尾页面兜底"） 把页面按业务价值分 P0 / P1 / P2：
- P0（首页、核心交易页，占 PV 的 20%）：RUM 100% 采样 + 严格告警 + 性能大盘
- P1（常用功能页，占 PV 的 50%）：Sentry 全量 + RUM 10% 采样 + 宽松告警
- P2（长尾配置页、管理后台，占 PV 的 30%）：Sentry 兜底 + RUM 1% 采样 + 不配告警
做法 D：用 SLO 驱动告警（"不是看指标，是看错误预算"） 不单独盯 LCP / FCP / 错误率，而是定义一个 composite SLO（比如"核心页面可用率 > 99.5% 且 P95 响应 < 3s"），错误预算烧完才告警。平时不响，响了就是真出事。
【我的倾向与理由】
我倾向 做法 C（按页面分级）+ 做法 D（SLO 驱动告警）的组合，理由：
- 可观测性的本质是「用最小成本覆盖最大风险面」。12 个页面里，真正影响营收和用户留存的可能只有 3-4 个（首页 + 核心交易链路），把 100% 的监控预算均匀撒在 12 个页面上，是典型的"撒胡椒面"。
- 告警的价值不在于"响了多少次"，而在于"响了之后团队是否真的去处理了"。5 条告警 79% 误报率，本质是告警阈值没有跟业务风险挂钩——LCP P75 > 4s 在 B 端产品里可能根本不是问题，但 JS 异常率 > 0.1% 可能就是白屏。
- 落地成本要算进去：RUM 全量上报的存储成本、SDK 的 bundle 体积影响（我们 SDK 占了 ~12KB gzipped，对 LCP 有影响）、维护自研 SDK 的人力成本。如果 P2 页面只保留 Sentry 兜底，SDK 可以做成"按需加载"，P0 页面才注入完整 RUM 采集。
具体我会怎么改：
- P0 页面（3 个）：RUM 100% 采样 + composite SLO 告警（错误预算 4h 烧完才响）
- P1 页面（5 个）：Sentry 全量 + RUM 10% 采样 + 仅 JS 异常率告警
- P2 页面（4 个）：Sentry 兜底，不配 RUM 告警
- 预计 RUM 存储量从 38GB/月降到 ~8GB/月，告警频率从 6 个月 34 次降到 < 10 次
【想听大家在什么场景下怎么选】
- 你们团队怎么给前端页面做"监控分级"？是按业务价值、按 PV 占比、还是按故障影响面？有没有踩过"分级分错了"的坑？
- RUM 采样率你们怎么定？有没有用自适应采样（异常时自动提采样率）的经验？
- 有没有遇到过"监控做得很全但没人看"的情况？你们怎么解决"大盘没人看"这个组织问题？（我觉得这比技术选型更关键）
- SLO 驱动告警在 B 端产品里落地难不难？错误预算怎么跟业务方对齐？
- 自研监控 SDK vs Sentry / LogRocket 等商业方案，你们的选型标准是什么？bundle 体积、上报成本、数据主权，哪个权重最高？
我不是想证明"三件套是过度设计"，而是想讨论：在资源有限的前提下，怎么把可观测性的钱花在刀刃上，同时不丢关键风险面。 尤其是 B 端 / 内部工具这类"用户不会投诉但业务会受影响"的场景，告警策略跟 C 端产品应该有哪些本质区别？
欢迎拍砖，也欢迎分享你们团队的实际做法和数据。