你的前端监控还在裸奔？这套 Sentry + RUM 组合把告警周期从天级压到了分钟级

线上用户报 bug，你还在等用户主动反馈？等反馈上来的时候，可能已经影响了成百上千的用户。

前端监控这事，做和不做，差的是两个完全不同的世界。大多数团队的问题是：监控工具装了一堆，但告警收不到、收到了也不知道怎么处理、处理完了也不知道怎么复盘。

我去年把这个问题彻底解决了一遍，用的是 Sentry + Performance API + RUM 这套组合。

监控体系到底要解决什么问题

先搞清楚你到底在监控什么。前端监控本质上就三件事：错误、性能、行为。

错误监控最直接，就是 JS 报错、接口异常、白屏崩溃。性能监控看的是页面加载速度、操作响应时间、资源加载情况。行为监控则更偏业务，比如用户路径、转化漏斗、操作失败率。

很多团队监控做不好，不是工具不够，是监控目标不清晰。装了 Sentry 但所有错误都往一个项目里塞，告警阈值设的太低导致告警风暴，最后大家直接关掉通知。

Sentry 不是装了就行，配置才是关键

Sentry 的安装本身很简单，但真正发挥价值靠的是后续配置。

第一个要配置的是告警规则。别用默认阈值，那是给小型项目参考的。真实项目的告警要分级别：Critical（影响核心功能）、High（影响部分用户）、Medium（需要关注但不需要立即处理）。每个级别的告警通道要分开，Critical 发钉钉/飞书电话通知，Medium 发邮件次日汇总就行。

// 告警规则配置示例
Sentry.init({
  dsn: "你的DSN",
  environment: process.env.NODE_ENV,
  // 采样率配置，生产环境不要采集100%
  tracesSampleRate: 0.1,
  // 针对特定错误类型设置不同的采样率
  sampleRate: 1,
  beforeSend(event) {
    // 过滤掉第三方脚本的错误
    if (event.tags?.source === "external") return null;
    return event;
  }
});

第二个要配置的是性能监控。Sentry 的 Performance 模块默认关闭，需要手动启用。启用后可以监控页面加载时间、接口响应时间、静态资源加载情况。关键是要设置合理的 transaction 名称规则，否则 Sentry 会把不同参数的请求当成不同的 transaction，数据完全没法看。

第三个要配置的是 Source Map 上传。这个直接影响错误定位的准确度。没有 Source Map 的错误堆栈，就像给你一张打了马赛克的照片——知道有问题，但看不清在哪。

Performance API：浏览器内置的性能眼睛

Performance API 是浏览器原生提供的性能数据接口，数据比任何第三方监控都准确，因为是浏览器自己测的。

// 获取核心 Web Vitals 数据
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.value);
  }
});

// 监控 LCP
observer.observe({ type: "largest-contentful-paint", buffered: true });
// 监控 INP
observer.observe({ type: "event", durationThreshold: 100, buffered: true });
// 监控 CLS
observer.observe({ type: "layout-shift", buffered: true });

Performance API 的数据要配合上报机制使用。我一般是这样做的：在页面加载完成后，把关键性能指标计算出来，通过 Beacon API 上报到自己的数据服务，或者直接打到 Sentry。

window.addEventListener("load", () => {
  setTimeout(() => {
    const paint = performance.getEntriesByType("paint");
    const navigation = performance.getEntriesByType("navigation")[0];

    const metrics = {
      fcp: paint.find(e => e.name === "first-contentful-paint")?.startTime,
      lcp: performance.getEntriesByType("largest-contentful-paint").pop()?.startTime,
      ttfb: navigation?.responseStart,
      domContentLoaded: navigation?.domContentLoadedEventEnd,
      load: navigation?.loadEventEnd
    };

    // 用 Beacon API 上报，不阻塞页面卸载
    navigator.sendBeacon("/api/metrics", JSON.stringify(metrics));
  }, 0);
});

RUM：真实用户的体验数据

Sentry 监控的是技术指标，RUM（Real User Monitoring）监控的是真实用户体验。两者结合才能全面。

RUM 的核心价值在于分人群、分地域、分设备的性能分析。同样是 3 秒的加载时间，高端机型用户可能觉得还行，但低端 Android 机用户可能已经崩溃了。同样是接口慢，在东南亚和在美国完全是两个问题。

如果预算有限，可以用 Sentry 的 Session Replay 功能，它提供了基础的 RUM 能力。如果预算充足，可以考虑 Datadog RUM 或者自己搭建基于 Performance API 的采集服务。

告警收敛：减少噪音才能保持敏感

告警多了等于没告警。我见过太多团队装了监控然后又关掉，根本原因就是告警太多太频繁。

告警收敛有几个常用策略：

第一是聚合告警。同一个接口的 100 个 500 错误，聚合为一条告警，而不是发 100 条。Sentry 默认支持这个，但需要配置。

第二是告警升级。同一个问题首次出现发通知，重复出现次数达到阈值才升级到电话通知。这样可以避免一次性的大规模故障把通知渠道打爆。

第三是静默规则。已知的计划内维护时间段、已知的第三方服务异常，直接静默，不要让这些信息分散注意力。

复盘机制：监控的终点是改进

告警处理完了就结束了？这是很多团队的通病。

每一次告警都应该有复盘。复盘不是追责，是找根因和预防措施。复盘结果要落地到：这个问题下次怎么提前发现？这个错误模式是否适用于其他场景？我们是否需要增加新的监控维度？

Sentry 的 Issue 详情页有 User Feedback 功能，可以让用户主动反馈问题。这个数据是监控体系的重要补充，因为技术指标只能告诉你”有问题”，不能告诉你”用户感受到的问题是什么”。

下一步：从监控到可观测

监控是被动的，可观测是主动的。监控告诉你什么时候出了问题，可观测告诉你为什么出问题、出在哪一层。

从监控到可观测，需要把前端数据、后端数据、业务数据打通。前端的错误和性能数据，要能和后端的链路追踪（如 OpenTelemetry）关联起来。这样才能做到端到端的根因分析。

这条路很长，但每一步都值得。先把 Sentry 配好，把告警收敛做好，再逐步加上 Performance API 数据和 RUM 数据，这套体系就成了。