前端性能监控实战：基于Web Vitals、Sentry与Grafana构建全链路可观测方案

原创于 2026-06-24 11:46:00 发布 · 1.3k 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#前端性能监控 #Web Vitals #Sentry

lucene 专栏收录该内容

11 篇文章

订阅专栏

1. 项目概述：为什么我们需要一套完整的前端性能监控方案？

做前端开发这些年，我越来越觉得，性能问题就像房间里的大象——大家都知道它存在，但很多时候都选择性地忽略，直到它把整个项目“撞翻”。以前我们排查线上问题，基本靠用户反馈和“猜”。用户说“页面卡”，我们只能凭经验去查网络请求、看代码逻辑，效率低不说，还经常找不准根因。后来，我们开始用一些零散的工具：用 Lighthouse 跑个分，用 Chrome DevTools 录个 Performance 面板，或者自己写点 Date.now() 来打点计算。但这些方案要么是离线的、非实时的，要么就是数据孤岛，无法形成全局视角，更别提建立长期的性能基线了。

直到 Google 提出 Web Vitals 这套核心用户体验指标，事情才开始变得清晰。它把“用户体验”这个模糊的概念，量化成了三个核心指标： LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累积布局偏移） 。这就像给了我们一把精准的尺子，去衡量用户到底“感觉”快不快、顺不顺。但光有尺子还不够，我们还需要一个“记录员”来持续测量，一个“警报器”在出问题时尖叫，以及一个“仪表盘”来展示全局趋势。这就是 Sentry 和 Grafana 登场的时候。

所以，这个项目的核心目标，就是用一套统一的代码和架构，把 指标采集（Web Vitals）、错误与性能追踪（Sentry）、数据可视化与告警（Grafana） 这三个环节彻底打通。它解决的不仅仅是“监控”问题，更是“可观测性”问题。我们不再被动响应，而是能主动洞察：新版本发布后，LCP 是否恶化？某个地区的用户 CLS 是否异常增高？某个特定交互的 FID 是否超出了可接受范围？这套方案能给你答案。

无论你是个人开发者想优化自己的博客，还是团队负责人需要为大型应用建立性能防线，这套从采集到展示的全流程实战指南，都能让你告别“盲人摸象”，真正掌控前端性能的脉搏。接下来，我会带你从零开始，一步步搭建这套系统，并分享我在实践中踩过的坑和总结的技巧。

2. 整体架构设计与工具选型逻辑

在动手写代码之前，我们先得把整个监控体系的蓝图画清楚。一个健壮的监控系统，绝不是把几个开源工具简单堆砌在一起，而是要根据数据流向和职责，进行清晰的分层设计。

2.1 核心架构分层

我设计的这套架构主要分为四层，数据自下而上流动：

数据采集层（客户端） ：这是源头，运行在用户的浏览器中。它的职责是“感知”用户体验，采集原始的 Web Vitals 指标、JavaScript 错误、资源加载错误、用户行为等数据。这一层要求代码轻量、无侵入、稳定可靠。
数据聚合与上报层 ：采集到的原始数据不能直接“扔”给后端。这一层负责在客户端进行初步的加工、聚合、节流，并选择可靠的传输方式将数据发送到指定的服务端接收点。这里要处理好网络不稳定、数据量大等问题。
数据处理与存储层（服务端） ：接收客户端上报的数据，进行验证、清洗、格式化，然后存入时序数据库或专门的事件存储中。这一层是数据的中枢，决定了数据的查询效率和存储成本。
数据可视化与告警层 ：将冰冷的数据转化为直观的图表和及时的告警。这一层需要提供灵活的查询能力、丰富的可视化组件，以及可配置的告警规则，让开发和运维人员能快速发现问题、定位根因。

2.2 为什么是 Web Vitals + Sentry + Grafana？

市面上监控工具很多，为什么偏偏是这三个组合？这是经过深思熟虑和实际踩坑后的选择。

Web Vitals：用户体验的“金标准” Google 将其作为搜索排名因子之一，这已经足够说明其重要性。它聚焦于用户最能直接感知的三个方面： 加载速度（LCP）、交互响应（FID/INP）、视觉稳定性（CLS） 。相比于传统的 DOMContentLoaded 、 onload 事件，Web Vitals 更能反映真实用户的感受。更重要的是，它有明确的“良好”、“需要改进”、“差”的阈值范围，让我们做优化和设定目标时有据可依。
Sentry：不止于错误监控的“瑞士军刀” 很多人对 Sentry 的印象还停留在错误收集。但现代的 Sentry 早已是一个强大的应用性能监控（APM）平台。它的核心优势在于 “关联性” 。
- 错误与性能关联 ：当一个页面错误发生时，Sentry 能同时捕获到当时的 Web Vitals 指标、用户操作轨迹、设备信息、网络状况等上下文。这让你排查错误时，能立刻知道是不是因为页面加载太慢导致脚本执行异常，或者是不是在低端设备上更容易复现。
- 强大的 Release 追踪 ：Sentry 可以与你的 CI/CD 流程深度集成，标记每一次代码发布。这样，你可以清晰地看到新版本上线后，错误率是升是降，性能指标有何变化，实现真正的“发布监控”。
- 用户反馈与会话回放 ：高级功能可以录制用户遇到问题时的操作序列，甚至收集用户反馈，这对于复现那些“难以描述”的诡异问题至关重要。选择 Sentry，就是选择了一个以“问题诊断”为中心的统一数据平台。
Grafana：可视化与告警的“终极画板” Sentry 自带的数据看板已经不错，但当我们想要进行更复杂的多维度分析、长期趋势对比，或者将前端性能数据与后端服务指标（如 API 响应时间、服务器负载）放在同一个视图中时，Grafana 是无可替代的。
- 数据源无关性 ：Grafana 可以连接 Prometheus、InfluxDB、Elasticsearch、甚至 Sentry 自身的数据源（通过插件或API）。这意味着你可以把前端性能数据和整个技术栈的其他监控数据融合分析。
- 灵活的仪表盘 ：拖拽式编辑，支持多种图表类型，可以构建从全局概览到深度下钻的各级别仪表盘。
- 强大的告警引擎 ：支持基于多数据源、多条件的复杂告警规则，并可以通过钉钉、企业微信、Slack、邮件等多种渠道通知，确保问题能被第一时间发现。

这个组合的协同效应 ：Web Vitals 提供标准化的输入，Sentry 进行深度的、关联性的处理和存储，Grafana 则提供宏观的、可定制的输出和预警。三者形成了一个从微观到宏观、从采集到响应的完整闭环。

注意：这套架构也考虑了扩展性。例如，未来如果你想加入自定义的业务性能指标（如“商品列表渲染完成时间”），只需在采集层增加相应的打点逻辑，数据可以一并流入 Sentry 或通过其他方式进入 Grafana 的数据源，架构无需大改。

3. 核心实现：从采集到上报的代码实战

理论讲完，我们进入最硬核的实操部分。我会手把手带你编写实现这套监控方案的核心代码，并解释每一个关键决策背后的原因。

3.1 使用 `web-vitals` 库进行指标采集

首先，我们需要在项目中采集 Web Vitals 数据。Google 官方提供了 web-vitals 这个库，它封装了不同浏览器下的复杂测量逻辑，是我们最好的选择。

安装与基础采集：

npm install web-vitals --save
# 或
yarn add web-vitals

接下来，我们在应用的入口文件（如 main.js 或 index.js ）中初始化采集。这里有一个非常重要的原则： 监控代码必须尽可能早地执行，且自身不能影响性能 。因此，我们通常采用异步加载的方式。

// monitor.js - 独立的监控模块
import { onLCP, onFID, onCLS } from 'web-vitals';

// 定义一个发送数据的函数，这里先简单用 console.log 代替，后续替换为真实上报
function sendToAnalytics(metric) {
  const body = {
    name: metric.name, // 'LCP', 'FID', 'CLS'
    value: metric.value, // 数值
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta, // 与上一次值的差值（用于 Cumulative Layout Shift）
    id: metric.id, // 当前指标实例的唯一ID
    // 添加上下文信息
    page: window.location.pathname,
    hostname: window.location.hostname,
    // 添加设备与网络信息（可选，但非常有用）
    effectiveType: navigator?.connection?.effectiveType,
    deviceMemory: navigator?.deviceMemory,
  };
  
  // 使用 navigator.sendBeacon 进行上报，它在页面卸载时也能可靠发送
  // 这里先打印，后面会替换为向 Sentry 和自有后端的上报逻辑
  console.log('[Web Vitals]', body);
  
  // 使用 Beacon API 发送（示例，目标URL需替换）
  // const blob = new Blob([JSON.stringify(body)], { type: 'application/json' });
  // navigator.sendBeacon('https://your-api-endpoint.com/vitals', blob);
}

// 注册核心 Web Vitals 的监听器
export function initWebVitals() {
  // 监听 LCP
  onLCP(sendToAnalytics);
  // 监听 FID (注意：FID 已被 INP 取代作为核心指标，但当前仍广泛使用)
  onFID(sendToAnalytics);
  // 监听 CLS，注意第三个参数 `reportAllChanges` 设为 true，以报告所有变化而非最终值
  onCLS(sendToAnalytics, { reportAllChanges: true });
  
  // 你也可以采集其他辅助指标，如 FCP、TTFB
  // import { onFCP, onTTFB } from 'web-vitals';
  // onFCP(sendToAnalytics);
  // onTTFB(sendToAnalytics);
}

关键点解析：

reportAllChanges: true for CLS ：CLS 是累积值，用户滚动页面可能引发新的布局偏移。设置这个参数为 true ，我们就能捕获到 CLS 的每一次变化，而不是只报告最终总值。这对于理解“何时发生偏移”至关重要。
添加上下文 ：光有指标值不够。我们同时上报了页面路径、主机名、网络类型( effectiveType )、设备内存等信息。这样在分析时，我们就能轻松地发现“是否慢速网络下的用户 LCP 更差？”或“某个特定页面的 CLS 是否异常？”这类问题。
navigator.sendBeacon ：这是用于数据上报的“正确姿势”。它在页面卸载（用户关闭标签页或跳转）时也能保证请求发出，且不会阻塞页面卸载过程，比传统的 fetch 或 XMLHttpRequest 在此时更可靠。

3.2 集成 Sentry：错误监控与性能追踪的深度融合

接下来，我们把 Sentry 集成进来，让它不仅能捕获错误，还能接收我们采集的 Web Vitals 数据，实现关联分析。

安装与初始化：

npm install @sentry/browser @sentry/tracing --save

// sentry.js
import * as Sentry from '@sentry/browser';
import { Integrations } from '@sentry/tracing'; // 注意：Sentry v7后，BrowserTracing 集成方式有变

export function initSentry() {
  Sentry.init({
    dsn: 'https://your-public-key@o0.ingest.sentry.io/your-project-id', // 从 Sentry 后台获取
    release: process.env.RELEASE_VERSION || 'unknown', // 关联代码版本，非常重要！
    environment: process.env.NODE_ENV || 'development',
    integrations: [
      // 启用浏览器追踪（性能监控）集成
      new Integrations.BrowserTracing({
        tracingOrigins: ['localhost', 'your-api-domain.com'], // 跟踪哪些后端的请求
      }),
    ],
    // 采样率：在生产环境，为了控制数据量，可以采样一部分用户的完整追踪
    tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.2 : 1.0, // 生产环境采样20%
    // 设置初始范围（Scope）的标签，便于后续筛选
    initialScope: {
      tags: {
        platform: 'web',
      },
    },
  });
  
  // 可选：设置用户信息（如果应用有登录）
  // Sentry.setUser({ id: user.id, email: user.email });
}

将 Web Vitals 数据发送到 Sentry： 现在，我们需要改造之前的 sendToAnalytics 函数，让它把数据同时发给 Sentry。Sentry 提供了 captureMessage 和设置自定义标签（Tags）、上下文（Contexts）的能力。但对于性能指标，更好的方式是使用 Sentry 的 测量（Measurement） API。

// 更新后的 sendToAnalytics 函数（在 monitor.js 中）
import * as Sentry from '@sentry/browser'; // 引入 Sentry

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname,
    hostname: window.location.hostname,
    effectiveType: navigator?.connection?.effectiveType,
    deviceMemory: navigator?.deviceMemory,
  };
  
  console.log('[Web Vitals]', body);
  
  // 1. 发送到自有后端（示例，使用 Beacon API）
  const blobForBackend = new Blob([JSON.stringify(body)], { type: 'application/json' });
  navigator.sendBeacon('https://your-monitoring-api.com/collect/vitals', blobForBackend);
  
  // 2. 发送到 Sentry
  // 方式一：作为自定义测量指标附加到当前事务（Transaction）上（推荐）
  // 首先获取当前活跃的事务（由 BrowserTracing 集成自动创建）
  const transaction = Sentry.getCurrentHub()?.getScope()?.getTransaction();
  if (transaction) {
    // 将 Web Vitals 指标记录为该事务的测量值
    transaction.setMeasurement(
      metric.name.toLowerCase(), // 测量名称，如 'lcp'
      metric.value,              // 测量值
      'ms' // 或 'none' for CLS，单位
    );
  }
  
  // 方式二：作为独立事件发送，并添加为标签和上下文（信息更独立）
  Sentry.withScope((scope) => {
    // 设置标签，便于在 Sentry 后台快速筛选
    scope.setTag('web-vitals', 'true');
    scope.setTag('vital.name', metric.name);
    scope.setTag('vital.rating', metric.rating);
    // 添加上下文信息，在事件详情中展示
    scope.setContext('Web Vitals', {
      ...body,
      // 可以添加更多细节
      navigationType: performance.getEntriesByType('navigation')[0]?.type,
    });
    // 使用 captureMessage 记录，级别为 info。这不是一个错误，而是一个性能事件。
    Sentry.captureMessage(`Web Vital recorded: ${metric.name} = ${metric.value}`, 'info');
  });
}

为什么这样设计？

双路上报 ：数据同时发往自有后端和 Sentry。自有后端用于存储原始数据，供 Grafana 拉取进行长期趋势分析和自定义聚合。Sentry 则用于错误关联和深度分析。两者互补。
关联到事务 ：方式一将指标绑定到用户会话的“事务”上。当这个会话中发生一个错误时，你可以在错误详情里直接看到当时的 LCP、FID 是多少，完美建立“性能差导致错误”的因果关系链。
独立事件 ：方式二创建了独立的性能事件。这在你想单独查看所有 Web Vitals 记录，或者当前没有活跃事务时很有用。你可以在 Sentry 的“事件流”中筛选 tag:web-vitals:true 来查看所有记录。

3.3 构建轻量级数据接收服务与 Grafana 数据源

为了在 Grafana 中展示漂亮的图表，我们需要一个持久化存储 Web Vitals 数据的地方，并暴露查询接口。这里有几个主流选择：

Prometheus + Grafana（经典组合） ：Prometheus 是时序数据库，擅长存储和查询时间序列数据。我们需要构建一个服务，接收前端上报的数据，并将其转换为 Prometheus 的指标格式（通常通过 /metrics 端点暴露）。
InfluxDB + Grafana ：InfluxDB 是另一个流行的时序数据库，其数据模型（Measurement, Tag, Field, Time）非常灵活，与 Web Vitals 的数据结构天然契合。
直接使用 Sentry 作为数据源 ：Sentry 提供了强大的查询 API。Grafana 有官方的 Sentry 数据源插件，可以直接查询 Sentry 中的事件数据，包括我们发送的 Web Vitals 事件。 这是最快速、运维成本最低的方案 ，特别适合初创团队或想快速上手的项目。

这里我以 方案三（Sentry数据源） 和 方案一（自建Prometheus接收器） 为例，分别说明。

方案A：使用 Grafana 的 Sentry 数据源插件

在 Grafana 中安装 “Sentry” 数据源插件。
配置插件，填入你的 Sentry 组织、项目以及 Auth Token。
现在，你可以在 Grafana 中直接编写查询，例如：
- query: events + filter: tag[vital.name]:LCP -> 可以查询所有 LCP 事件。
- 利用 Grafana 的 Transform 功能，计算这些事件值的平均值、分位数（P75， P95）等。
- 优点：无需自建后端，直接利用 Sentry 的存储和查询能力。数据与错误上下文天然关联。
- 缺点：查询复杂度受 Sentry API 限制，长期存储成本可能较高（取决于 Sentry 套餐）。

方案B：自建 Prometheus 接收器（Node.js示例） 如果你需要更复杂的查询、更长期的低成本存储，或者想融合其他系统指标，自建接收器是更好的选择。

// server/prometheus-receiver.js (Node.js with Express)
const express = require('express');
const client = require('prom-client'); // Prometheus 客户端库
const app = express();
app.use(express.json());

// 创建 Prometheus 指标
const registry = new client.Registry();
// 定义一个直方图（Histogram）来存储 Web Vitals，它可以计算分位数（如P75, P95）
const webVitalsHistogram = new client.Histogram({
  name: 'web_vitals_seconds',
  help: 'Web Vitals metrics from browser',
  labelNames: ['name', 'rating', 'page', 'effective_type'], // 标签，用于多维度查询
  buckets: [0.1, 0.25, 0.5, 1, 2.5, 5, 10], // 桶定义，用于直方图统计。单位是秒，LCP/FID需要转换。
  registers: [registry],
});

// 暴露 Prometheus 指标的端点（Grafana 通过这个地址拉取数据）
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', registry.contentType);
  res.end(await registry.metrics());
});

// 接收前端上报数据的端点
app.post('/collect/vitals', (req, res) => {
  const metric = req.body;
  
  // 验证必要字段
  if (!metric.name || metric.value === undefined) {
    return res.status(400).send('Invalid data');
  }
  
  // 将毫秒转换为秒（Prometheus 标准单位）
  const valueInSeconds = metric.value / 1000.0;
  
  // 记录到直方图指标中
  webVitalsHistogram.observe(
    {
      name: metric.name, // LCP, FID, CLS
      rating: metric.rating || 'unknown',
      page: metric.page || 'unknown',
      effective_type: metric.effectiveType || 'unknown',
    },
    valueInSeconds
  );
  
  console.log(`Received ${metric.name}: ${metric.value}`);
  res.status(200).send('OK');
});

app.listen(3001, () => {
  console.log('Prometheus receiver listening on port 3001');
});

前端上报代码对应修改： 将之前 sendToAnalytics 函数中的 your-monitoring-api.com 替换为这个接收服务的地址。

在Grafana中配置Prometheus数据源：

在 Grafana 中添加数据源，选择 “Prometheus”。
URL 填写你的接收器服务地址（如 http://your-server:3001 ）。
保存后，你就可以使用 PromQL 查询数据了，例如：
- histogram_quantile(0.75, rate(web_vitals_seconds_bucket{name="LCP"}[5m])) 计算 LCP 的 P75 值。
- rate(web_vitals_seconds_count{name="CLS", rating="poor"}[5m]) 计算过去5分钟 CLS 为 “差” 的比率。

4. 数据可视化与告警配置实战

数据有了，下一步就是让它们“说话”。我们将在 Grafana 中创建仪表盘和告警规则。

4.1 构建核心 Web Vitals 仪表盘

在 Grafana 中新建一个 Dashboard，我们可以创建以下几个核心面板：

全局状态概览（Stat） ：
- 查询：分别查询 LCP、FID、CLS 在过去一段时间内（如24小时）处于 “good” 评级的数据点比例。这需要你的数据模型支持 rating 标签。
- 展示：使用 “Stat” 面板，显示百分比，并可以配置颜色阈值（绿色 > 90%，橙色 > 75%，红色 < 75%），一目了然。
核心指标趋势图（Time series） ：
- LCP / FID / CLS 的 P75、P95 随时间变化曲线 。这是最重要的图表，能看出性能的长期趋势和版本发布的影响。
- 查询示例（PromQL） ：
```
# LCP P75 (假设单位已转为秒)
histogram_quantile(0.75, rate(web_vitals_seconds_bucket{name="LCP"}[$__rate_interval]))
# LCP P95
histogram_quantile(0.95, rate(web_vitals_seconds_bucket{name="LCP"}[$__rate_interval]))
```
- 将两条曲线画在同一坐标系，并添加一条代表“良好”阈值的参考线（如 LCP 2.5秒）。这样能清晰看到有多少比例的用户体验超标。
多维度下钻分析（Table 或 Bar gauge） ：
- 按页面分解 ：一个表格，列出访问量前10的页面及其各自的 LCP P95 值。快速定位问题页面。
- 按网络类型分解 ：比较 4g , 3g , 2g , slow-2g 网络下用户的 FID 差异。这能帮你发现是否需要为弱网环境做更多优化。
- 查询示例 ：
```
# 按页面和评分统计数量
sum by (page, rating) (rate(web_vitals_seconds_count{name="LCP"}[5m]))
```

4.2 配置智能告警规则

监控的最终目的是为了及时发现问题。Grafana 的告警功能非常强大。

告警规则示例（在 Grafana Alerting 中配置）：

关键指标恶化告警 ：
- 规则名称 ： LCP-P95-恶化
- 查询： histogram_quantile(0.95, rate(web_vitals_seconds_bucket{name="LCP"}[5m]))
- 条件： WHEN last() OF query(A, 5m, now) IS ABOVE 4 （当最近5分钟的LCP P95值持续高于4秒时）
- 评估频率 ：每1分钟评估一次。
- 通知渠道 ：配置连接到钉钉/企业微信机器人、Slack频道或邮件组。
“差”评率激增告警 ：
- 规则名称 ： 高CLS差评率
- 查询A（差评数） ： sum(rate(web_vitals_seconds_count{name="CLS", rating="poor"}[5m]))
- 查询B（总数） ： sum(rate(web_vitals_seconds_count{name="CLS"}[5m]))
- 条件： WHEN (A / B) IS ABOVE 0.1 （当CLS差评率超过10%时）
- 这种比例告警比绝对值告警更灵敏，能发现用户体验的整体下滑。
版本对比告警（高级） ：这需要你的数据中包含 release 标签（从Sentry集成或自定义上报中获得）。
- 查询：分别计算当前版本和上一个版本的 LCP P75。
- 条件： WHEN (current_release_lcp / previous_release_lcp - 1) IS ABOVE 0.2 （当当前版本比上一版本慢20%以上时触发）。
- 这种告警能在新版本上线后自动评估性能回归，是持续交付中的重要质量关卡。

实操心得 ：告警切忌“狼来了”。一开始可以把阈值设得宽松一些，避免频繁误报导致团队麻木。然后根据历史数据观察，逐步收紧阈值。告警信息中一定要包含关键标签，如 page 、 release ，方便接收人快速定位问题范围。

5. 部署、优化与高级实践

将这套系统部署到生产环境，并确保其高效稳定运行，还需要考虑一些工程化细节。

5.1 前端SDK的打包与加载优化

监控代码也是代码，不能拖慢应用本身。

代码分割与异步加载 ：不要将监控 SDK 打包到主应用 bundle 中。应该将其构建为独立的 chunk，并通过 <script async> 或动态 import() 异步加载。

<!-- 在 HTML 中异步加载 -->
<script async src="/path/to/your-monitor.chunk.js"></script>

// 或在应用初始化后动态加载
if (process.env.NODE_ENV === 'production') {
  import('./monitor').then(({ initWebVitals, initSentry }) => {
    initSentry();
    initWebVitals();
  });
}

Tree Shaking ：确保你的打包工具（如 Webpack、Rollup）能对 web-vitals 和 @sentry 库进行 Tree Shaking，只引入用到的部分。
CDN 与非阻塞加载 ：考虑将 Sentry 的浏览器 SDK 通过其 CDN 加载，并配置 data-lazy="no" 等属性，优化加载时机。

5.2 采样与数据降噪

全量上报所有用户的所有数据，成本高昂且可能不必要。

采样率（Sample Rate） ：如前面 Sentry 初始化所示，通过 tracesSampleRate 控制性能事务的采样率。对于错误监控，Sentry 也有 sampleRate 选项。在生产环境，从较低采样率（如10%）开始，根据数据量和需求调整。

用户采样 ：可以在前端实现一个简单的随机逻辑，只对特定比例的用户开启完整的性能指标采集。

function shouldSampleUser(sampleRate = 0.1) {
  return Math.random() < sampleRate;
}
if (shouldSampleUser(0.1)) {
  initWebVitals(); // 只对10%的用户采集Web Vitals
}
// Sentry错误监控通常保持较低但全量的采样，因为错误更需要被捕获
initSentry();

过滤噪音 ：可以过滤掉一些无意义或干扰性的数据。例如，过滤掉页面停留时间极短（如小于3秒）的会话数据，因为其性能数据可能不完整。

5.3 与CI/CD流程集成

真正的监控是“左移”的，需要与开发流程结合。

在Sentry中创建Release ：在构建脚本中，使用 Sentry CLI 创建 Release 并上传 Source Map。这样线上报错时，看到的是还原后的源代码，而非压缩后的代码。

export SENTRY_RELEASE=$(git rev-parse --short HEAD)
sentry-cli releases new $SENTRY_RELEASE
sentry-cli releases files $SENTRY_RELEASE upload-sourcemaps ./dist --url-prefix '~/static/js'
sentry-cli releases finalize $SENTRY_RELEASE

性能回归测试 ：在 CI 流水线中，可以加入基于 Lighthouse CI 或 Puppeteer 的性能测试，设定 LCP、CLS 等指标的预算（Budget），如果合并的代码导致性能预算超标，则阻塞合并。

5.4 排查与调试技巧

当告警响起，或者发现数据异常时，如何快速定位问题？

在Sentry中关联查看 ：收到一个“JS运行时错误”告警。立刻去 Sentry 找到该错误事件。在事件详情中，检查“Breadcrumbs”（面包屑）和“Context”（上下文）。你很可能直接看到错误发生前一刻的 LCP 、 FID 值，以及用户的操作序列、网络状况。如果发现错误发生时 LCP 很高，那么问题的根源可能就是加载性能问题，而非代码逻辑错误。
在Grafana中下钻分析 ：发现整体 LCP P95 飙升。在 Grafana 仪表盘上：
- 首先，查看“按页面分解”的面板，确认是全局性问题还是某个特定页面引起的。
- 然后，查看“按网络类型分解”面板，确认是否只在特定网络环境下恶化。
- 接着，将时间范围缩小到开始飙升的具体时刻，结合部署记录，看是否与某次发布相关。
- 如果数据包含了 release 标签，直接对比发布前后的数据曲线。
利用浏览器真实用户监控（RUM）工具 ：像 Sentry Performance 或商业化的 RUM 产品（如 Dynatrace, New Relic）提供了更细粒度的会话回放和资源加载瀑布图。对于复杂问题，可以筛选出特定时间段内性能差的真实用户会话，直接回放其加载过程，查看是哪个具体资源（图片、JS、CSS）或 API 请求拖慢了页面。
常见的性能模式与根因 ：
- LCP 过高 ：检查是否是首屏大图或字体文件未优化、未使用 loading="eager" 或 preload ？是否是关键 API 响应慢？是否是主线程被长任务阻塞？
- FID/INP 过高 ：检查事件监听器中是否有同步的复杂计算？是否使用了非 passive 的滚动监听器？第三方脚本是否阻塞交互？
- CLS 过高 ：检查图片和媒体元素是否定义了尺寸（ width / height ）？广告、嵌入内容是否动态注入？字体加载是否会导致布局抖动？