前端性能监控 Sentry 接入全流程从 SDK 集成到告警策略的实战配置一、JS 错误监控与实际用户体验的断层一个电商前端项目的window.onerror每天捕获 2000 条错误。Uncaught TypeError: Cannot read properties of null 占 40%但这些错误都是生产环境的真实错误吗分析后发现其中 35% 来自 Chrome 插件注入的脚本、10% 来自爬虫程序、15% 来自过时的浏览器版本。真正影响用户体验的错误不到一半。原始的 JS 错误捕获面临三个问题噪音过滤——区分插件错误和业务错误上下文关联——一个错误发生时用户正在执行什么操作影响评估——一个错误影响了 1 个用户还是 1000 个用户。Sentry 解决的是从错误信号到可行动问题的转化。它不仅捕获错误还捕获错误发生前的面包屑用户点击、网络请求、控制台日志让排查不再依赖复现步骤。二、Sentry 的数据采集与处理流程graph TB BROWSER[浏览器端] -- INIT[Sentry.init 初始化] INIT -- CAPTURE[自动捕获] subgraph 自动捕获的事件 CAPTURE -- E1[未捕获的异常] CAPTURE -- E2[Promise Rejection] CAPTURE -- E3[手动 Sentry.captureException] end subgraph 上下文收集 E1 -- CTX1[面包屑点击/导航/请求] E2 -- CTX2[用户信息ID/IP] E3 -- CTX3[Release 版本号] end CTX1 -- ENRICH[数据丰富] CTX2 -- ENRICH CTX3 -- ENRICH ENRICH -- FILTER{过滤规则} FILTER --|通过| SEND[发送到 Sentry] FILTER --|丢弃| DROP[忽略已知非业务错误] SEND -- GROUP[Sentry 服务端br/错误分组] GROUP -- ALERT[告警规则匹配] ALERT -- NOTIFY[Slack/邮件通知]Sentry 在数据采集阶段就进行过滤不将无价值的错误发送到服务端。错误到达服务端后通过指纹fingerprint算法将相同的错误归组避免同一问题产生多个 Issue。三、Sentry SDK 的生产级配置// sentry.config.ts // 设计意图初始化 Sentry 并配置过滤规则、采样率和上下文 import * as Sentry from sentry/nextjs; Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN, // 环境标识——在 Sentry 看板中区分开发/灰度/生产 environment: process.env.NEXT_PUBLIC_APP_ENV || production, // Release 版本——关联到 Git commit hash release: process.env.NEXT_PUBLIC_RELEASE_VERSION, // 采样率配置 // 错误采样——生产环境 100% 采集 sampleRate: 1.0, // 性能追踪采样——生产环境 10% 采样以控制成本 tracesSampleRate: process.env.NODE_ENV production ? 0.1 : 1.0, // 过滤规则 // 忽略特定错误——插件注入、爬虫、浏览器兼容性 ignoreErrors: [ top.GLOBALS, chrome-extension://, moz-extension://, Network request failed, AbortError, ResizeObserver loop limit exceeded, ], // 更灵活的过滤——通过函数判断 beforeSend(event, hint) { const error hint.originalException; // 过滤爬虫——User Agent 中包含 bot 字符串 if (typeof navigator ! undefined) { const ua navigator.userAgent?.toLowerCase() || ; if (/bot|crawler|spider|scraper/i.test(ua)) { return null; // 返回 null 丢弃事件 } } // 过滤老浏览器——ES6 不支持的浏览器 if (error instanceof SyntaxError) { return null; } // 为错误添加自定义标签——便于在 Sentry 中筛选 if (event.tags) { event.tags.app_version process.env.NEXT_PUBLIC_APP_VERSION; } return event; }, // 性能监控 面包屑 integrations: [ Sentry.browserTracingIntegration(), Sentry.browserProfilingIntegration(), Sentry.replayIntegration({ maskAllText: true, blockAllMedia: true, }), Sentry.breadcrumbsIntegration({ console: false, fetch: true, xhr: true, }), ], });// ErrorBoundary 组件——捕获 React 组件树中的错误 // 设计意图在错误边界内展示降级 UI 并上报 Sentry import React from react; import * as Sentry from sentry/nextjs; interface ErrorBoundaryProps { children: React.ReactNode; // 降级 UI——可自定义 fallback?: React.ReactNode; // 错误发生时的回调 onError?: (error: Error) void; } interface ErrorBoundaryState { hasError: boolean; error: Error | null; } export class SentryErrorBoundary extends React.Component ErrorBoundaryProps, ErrorBoundaryState { constructor(props: ErrorBoundaryProps) { super(props); this.state { hasError: false, error: null }; } static getDerivedStateFromError(error: Error): ErrorBoundaryState { return { hasError: true, error }; } componentDidCatch(error: Error, errorInfo: React.ErrorInfo): void { // 上报到 Sentry——附带组件栈信息 Sentry.withScope((scope) { scope.setContext(react, { componentStack: errorInfo.componentStack, }); Sentry.captureException(error); }); this.props.onError?.(error); } render(): React.ReactNode { if (this.state.hasError) { // 降级 UI——默认展示友好的错误提示 return this.props.fallback || ( div classNameerror-boundary-fallback p页面出现了意外错误请刷新重试/p button onClick{() window.location.reload()} 刷新页面 /button /div ); } return this.props.children; } }三个关键配置决策tracesSampleRate: 0.1——生产环境只采样 10% 的性能数据控制成本Sentry 按事件量计费beforeSend过滤爬虫和插件错误——减少噪音事件量约 30%Session Replay 只录制错误 Session——全量录制成本高且有隐私风险。四、告警策略的设计原则告警疲劳的预防。一个错误即使影响 100 个用户如果它已经存在于 Sentry 中 3 个月且修复计划已排期就不需要每次出现都发告警。告警应该针对新出现或恶化的问题而非持续存在的问题。错误影响力而非数量的告警。1000 次同一种错误如某按钮在特定浏览器下报错可能只影响 5 个用户反复触发。告警应该基于影响的用户数而非事件发生次数。按环境影响告警级别。生产环境的 10 次错误需要 P1 告警灰度环境的同样 10 次错误可能只需要 P3 通知。在 Sentry 中按environment标签设置不同的告警规则。五、总结Sentry 前端监控的关键配置过滤规则——在beforeSend中过滤插件、爬虫、老浏览器错误采样率——生产环境 tracesSampleRate 不超过 0.1控制成本ErrorBoundary——配合 Sentry 上报组件栈信息展示降级 UI告警策略——基于影响用户数而非事件次数区分环境告警级别。落地步骤SDK 初始化并配置ignoreErrors过滤已知噪音部署后观察一周根据 Sentry Issue 列表补充过滤规则接入 Slack 告警设置新 Issue 5 分钟内影响 10 个用户的告警条件每月 Review Sentry 中最频繁的 10 个 Issue纳入修复排期。