前端 Web Vitals + 异常监控采集方案对比（Sentry vs OpenTelemetry Web SDK vs 自研 RUM）+ 可落地 TypeScript 采集骨架

背景

我团队目前用 Sentry 做前端错误监控，但 Web Vitals（LCP / INP / CLS）采集覆盖率只有 60%，告警链路断裂——异常采样率与 Vitals 采样率不统一，Loki + Grafana 侧看不到完整的性能-异常关联视图。想系统评估三条路线，做一个有数据支撑的选型决策，而不是拍脑袋。

三条候选路线：

1. Sentry 全家桶（Performance + Session Replay + Issue 关联），保留现有 SDK
2. OpenTelemetry Web SDK（@opentelemetry/sdk-trace-web + @opentelemetry/web）自采集，数据灌入已有 Loki + Grafana
3. 自研轻量 RUM SDK（TypeScript，目标 ≤ 800 行），覆盖核心指标 + 异常捕获，上报走自有网关

最终要什么

一份可决策的对比报告 + 一个可跑通的 TypeScript 采集 SDK 骨架 + 落地成本评估，让 10 人团队也能直接按结论落地，不需要再二次调研。

输入与上下文

• 技术栈：React 18 + Vite 5 + TypeScript 5.x
• 规模：日均 UV ≈ 50 万，月 API 请求 ≈ 8000 万
• 后端：已有 Loki + Grafana（非 Sentry 专属），无独立 Prometheus 实例
• 浏览器兼容：iOS Safari 15+ / Android Chrome 90+ / 桌面主流
• 约束：SDK 包体积 gzip 后 ≤ 30 KB（自研路线）；Sentry 路线可放宽到 ≤ 80 KB

交付格式（3 项）

1. Markdown 对比报告（≥ 2000 字）

   • 五维对比表：覆盖指标数、采样精度与去重策略、SDK 体积（gzip）、后端依赖、年成本估算（含 SaaS 费用或自运维人天）
   • 决策矩阵（加权打分，权重可调），附 10 人 / 50 人 / 200 人三种团队规模的推荐
   • 每条结论附具体版本引用（如 Sentry 8.x、OTel Web SDK 2.x、PerformanceObserver API 兼容性）

2. TypeScript 采集 SDK 骨架（≤ 800 行）

   • 覆盖 5 个核心指标：LCP / INP / CLS / JS Error（含 unhandledrejection）/ Resource Error
   • 上报通道：Beacon API 优先，降级 XHR；支持离线队列（localStorage，≤ 200 条）
   • 采样策略：Vitals 100% 采样 + 异常 100% 采样 + 资源错误 10% 采样（可配）
   • 入口单文件 rum-sdk.ts，npx tsx rum-sdk.ts 可在 Node 环境跑通 mock 上报
   • 含 README.md：接入示例（React SPA）+ 配置项说明

3. 落地成本评估（Markdown 表格）

   • 覆盖 3 种团队规模（10 人 / 50 人 / 200 人）
   • 每个规模含：实施人天估算（人日）、基础设施成本（SaaS 月费 vs 自运维硬件/云资源）、年 TCO 对比
   • 标注关键假设（如 Sentry Team Plan 定价、Loki 自运维人力等）

边界场景（报告须覆盖 ≥ 5 个）

• 移动端 WebView（iOS WKWebView / Android X5）下 PerformanceObserver 可用性
• 离线 / 弱网恢复上报（队列去重与幂等）
• CSP 限制下的 SDK 注入方式（script-src 白名单 vs nonce）
• 多 Tab 场景下 LCP / INP 的归因与去重
• 微前端（qiankun / Module Federation）下跨子应用指标归属

验收标准

见 acceptanceCriteria 字段。