1. 前端监控的“最后一公里”问题做前端时间久了大家都会遇到同一个尴尬线上出了bug用户截图发群里后端拿着日志说“参数没问题”前端这边却连复现的入口都找不到。问题出在哪大多数团队不是没有监控而是监控太碎——性能数据、异常数据、用户行为各存各的彼此没有关联出了问题根本拼不出完整的现场。WebTracing 这类方案解决的正是这个问题。它不是单纯做“错误上报”或者“性能统计”而是把埋点、行为、性能、异常、请求、资源、路由、曝光、录屏九个模块统一进一条链路让每一次用户操作都能关联到对应的请求、渲染耗时、报错信息乃至屏幕画面。它的价值在于当你说“用户下单失败”的时候你能同时看到用户点了哪里、页面卡了多久、哪个接口报了什么错、当时的屏幕长什么样。我最早接触这类体系是在一个日活百万级的 H5 电商项目上。当时线上经常反馈“支付页白屏”传统统计平台只能告诉你“白屏率3%”但没人说得清是哪些机型、哪个版本、哪个路由触发的。后来用了排查工具才定位到一个客户端 WebView 对 ES2020 语法支持的兼容性问题。这次经历让我下定决心把前端监控当做一个完整的系统来做而不是零散地堆几个埋点。这篇文章就想从WebTracing这类监控体系的整体设计出发把这九个核心模块怎么分工、怎么串联、落地时有哪些坑、以及常用实现思路都梳理一遍。不管你是刚开始搭监控体系还是已经在用某款开源方案都可以对照着看看哪些环节值得补强。2. 九个监控模块的功能拆分与定位2.1 埋点与行为用户到底做了什么埋点是整个监控体系的“地基”。行为数据则是埋点采集到的结果两者一个讲“怎么采”一个讲“采到什么”。行业内说的埋点一般分三种代码埋点在每个关键位置手动写上报逻辑比如“加入购物车”“提交订单”“切换Tab”精准但是费人力。可视化埋点通过配置圈选页面元素不需要改代码就能埋点适合运营快速接入。无埋点也叫全埋点自动采集所有点击、滚动、输入事件先存下来之后需要分析哪块分析哪块。缺点是数据量巨大对采样和存储要求很高。一个成熟的 WebTracing 方案通常会把“无埋点代码埋点”结合起来无埋点负责覆盖面上的行为代码埋点负责盯住关键流程。具体落地时点击事件用事件委托一层捕获避免在成千上万个节点上各自安监听器滚动和输入事件必须节流处理否则一个长列表页面就能把你的上报队列打爆。行为数据记录什么核心是“用户标识 行为时间 行为类型 行为目标 页面上下文”。用户标识可以是userId也可以是设备生成的UUID行为目标要记事件元素的自定义属性推荐data-track-id而不是只记innerText——因为文案经常改一改就会导致埋点数据断裂。2.2 性能与资源从白屏到可交互的耗时拆解性能监控在WebTracing里是硬骨头难的不是采集而是“怎么定义一次加载”。业界已经有一套共识核心是以 Web Vitals 为主LCP 看最大内容绘制FCP 看首屏内容出现CLS 看布局抖动INP 看交互延迟。配合资源加载数据可以拆出 DNS 解析、TCP 连接、TLS 握手、TTFB、内容下载等各阶段耗时。但实践里我建议再加两个指标白屏时间从导航开始到第一个元素渲染和可交互时间TTI的一种近似。这两个指标虽然不是标准 Web Vitals但对H5页面体验最直观。资源监控要分开看“静态资源”和“接口请求”。静态资源用 PerformanceObserver 监听 resource 条目能拿到每个 JS、CSS、图片的加载耗时和体积接口请求的耗时我会放到“请求模块”单独采集因为它还涉及成功失败和业务状态码混在一起容易乱。这里有一个常见的执行顺序问题PerformanceObserver 必须在页面加载早期注册否则你会发现首屏的条目一个都收不到。建议用performance.getEntriesByType(paint)回捞已经产生的结果再把 observer 注册好兜住后续数据两种方式互补才不会漏。2.3 异常与请求错误分类和网络层还原异常和请求是两个模块但它们经常需要联合排查。异常监控这里很多新手只会window.addEventListener(error)和window.addEventListener(unhandledrejection)这两个确实要监听但还不够。还有几类异常经常被漏掉资源加载异常img、link、script加载失败走的是带 capture 的 error 监听区分一下event.target是不是window。跨域脚本报错会显示Script error.拿不到详情需要后端给 script 标签加crossoriginanonymous响应头配合Access-Control-Allow-Origin。Vue/React 框架层错误Vue 的errorHandler、React 的ErrorBoundary都要单独接入否则组件内部抛错会被框架吞掉。白屏异常页面渲染失败但 console 没有明显报错需要靠采样DOM节点数来判断这个后面在排查部分细说。请求监控通常用代理拦截 XHR 和 Fetch。关键字段是请求URL、请求方法、请求体摘要、状态码、耗时、响应体摘要、业务错误码。我一般会把接口返回里的code字段单独抽出来存因为HTTP 200不代表业务成功“下单失败”这种错误在HTTP层面是看不出来的。拦截请求有个细节Fetch 的response.body是流式数据一旦被消费就无法二次读取。需要先clone()一份再处理或者不直接读body只记录body的size避免影响业务逻辑。2.4 路由、曝光与录屏还原完整会话现场路由、曝光、录屏排在后面是因为它们不是独立的基础监控而是“场景还原”能力。路由监控在SPA应用里很关键核心解决的是“用户从哪跳到哪”的路径问题。要注意的是history路由和hash路由要分别处理hash变化监听hashchangehistory变化覆盖pushState、replaceState和popstate。覆盖history方法时要保留原始方法的引用重写后用函数式调用否则会破坏应用自身的路由跳转逻辑。曝光监控负责记录“用户看到了什么”。实现上推荐 IntersectionObserver而不是实时计算getBoundingClientRect()——后者的同步布局开销在滚动场景下非常明显。曝光要定义好触发条件比如元素进入视口比例超过50%且持续1秒算有效曝光避免快速滚动造成大量无效数据。同一个元素重复曝光要不要上报我建议设计成“首次进入就上报离开视口再回来记第二次”并记录时间戳这样才能还原真实的注意力轨迹。录屏是重武器它不只记录用户鼠标轨迹而是以“帧”为单位记录整块屏幕的变化情况。前端录屏方案大多基于“DOM快照 增量日志”的思路经典库如 rrweb原理是通过序列化DOM来替代传统的“截屏传图”首次记录整棵DOM树的结构快照之后每隔一个时间片段只记录增量变化属性变更、节点增删、输入变化消费者端再用这些日志重放。这样数据量比视频小几个数量级还原度却能做到像素级。三个模块放在一起相当于把“用户路径路由 用户视线曝光 用户操作的完整画面录屏”整合到一起。排查问题时先看路由找到了入口再看曝光确认用户确实看到报错弹窗最后拉录屏看用户到底点了什么整个现场就复原了。3. 关键实现细节与实操要点3.1 数据采集层的模块划分与拦截方案整个WebTracing的SDK我推荐采用插件化架构。核心只有一个“采集管道”各模块作为插件注入。这么做的好处是按需加载业务方不需要把所有监控都引入模块解耦录屏出问题不影响基础异常上报。核心管道要提供四个能力init初始化配置、send上报数据、hook注册生命周期、store暂存数据。各插件负责自己的数据采集和格式化然后统一交给管道处理。管道这一层只关心三件事数据有没有效、要不要采样、什么时候上报。请求拦截和错误监听这类“全局性”的操作建议在init时一次性完成并且要做“重复初始化保护”。常见的坑是开发环境热更新导致模块重新执行监听器绑了一堆一份错误报了好几次。解决方式是在模块里维护一个初始化标记或者把监听器保存在一个全局Set里初始化前去重。性能数据采集要特别注意“时机”。页面首次加载性能最好在load事件后延迟一段时间再采集确保performance缓冲区的条目都落定路由切换产生的性能数据则要在对应操作后setTimeout几百毫秒采集给渲染留出时间。太早取数据经常只能拿到一半。3.2 数据关联与Trace链路设计九大模块采集到的数据如果不能关联价值会大打折扣。数据串联的核心字段是“会话ID 用户ID 页面ID 时间戳”。会话ID在SDK初始化时生成一个UUID存在 localStorage 里跨页面跳转保持同一会话直到用户关闭浏览器或者会话超时比如30分钟无操作算一次会话结束。用户ID登录态拿到后通过setUser方法动态传入。页面ID每次路由切换都会生成一个新的页面ID同时记录上一个页面ID形成页面跳转链。时间戳统一使用服务端校准后的时间避免用户设备时钟偏差导致时序错乱。这四个字段组成一个“横向关联维度”。再设计一个“纵向时间轴”把所有埋点事件按pageId分桶一次页面访问对应一个bucketbucket里存该页面相关的性能、异常、请求、曝光数据。查询的时候只要定位到某个pageId整个页面的“一生”都串起来了这就是录屏重放能精准定位到具体时间段的基础。我在实际落地时还会再加一个“traceId”由前端每次请求自动带在header里后端网关原样透传。这样前后端日志能对得上号排查慢接口时能直接去看后端的全链路trace定位是哪一层数据库查询拖慢了响应。3.3 上报策略批量、采样与优先级监控SDK最害怕的是“为了监控业务反而被监控拖垮”。上报策略是实现低开销监控的关键我的配置方式是这样批量上报数据不实时发而是放进队列每10秒或者队列满50条才合并成一次请求发送。请求用sendBeacon优先页面卸载的场景只有它能保证发出如果浏览器不支持再降级成fetch keepalive或者image打点。在HTML5页面里unload期间发XHR基本必丢用sendBeacon是唯一稳妥的方案。采样策略性能数据和录屏数据要采样。性能数据不必全量采集我一般按10%比例采样或者高峰期抽样录屏数据采样率要更低5%左右即可。异常数据和关键业务埋点必须全量一是错误量级本来不大二是漏掉一条就等于漏掉一个线上事故。请求优先级异常上报优先级最高可以独立于队列立刻发送其次是关键行为埋点性能数据和录屏排在最后允许延迟甚至丢弃。实现时可以给队列里的每条数据打level标记flush时先捞高优先级的打包发送防止低优先级数据挤占了带宽导致核心数据丢失。3.4 录屏模块的隐私脱敏与数据压缩录屏上线前隐私是必须过的门。回放中如果出现用户输入的手机号、身份证号、密码不仅是体验问题还会引发合规风险。隐私脱敏有三种做法黑名单属性对input[typepassword]或带>// 核心管道 class TracingCore { constructor(options) { this.config { ...options }; this.queue []; this.plugins new Map(); this.sessionId this.getSessionId(); } use(pluginName, plugin) { this.plugins.set(pluginName, plugin); plugin.init(this); return this; } send(type, data) { this.queue.push({ type, sessionId: this.sessionId, pageId: this.getPageId(), userId: this.userId || , ts: Date.now(), ...data }); if (this.queue.length (this.config.batchSize || 50)) { this.flush(); } } // 每10秒批量上报页面卸载用sendBeacon兜底 flush() { if (!this.queue.length) return; const payload this.queue.splice(0); if (navigator.sendBeacon) { navigator.sendBeacon(this.config.endpoint, new Blob([JSON.stringify(payload)], { type: application/json })); } else { fetch(this.config.endpoint, { method: POST, body: JSON.stringify(payload), keepalive: true, headers: { Content-Type: application/json } }); } } } // 异常插件 class ErrorPlugin { init(core) { window.addEventListener(error, (e) { if (e.target ! window) { // 资源加载错误图片、script、link core.send(resourceError, { source: e.target.tagName, src: e.target.src || e.target.href }); } else { core.send(jsError, { message: e.message, stack: e.error ? e.error.stack : , lineno: e.lineno, colno: e.colno }); } }, true); window.addEventListener(unhandledrejection, (e) { core.send(promiseError, { message: e.reason e.reason.message ? e.reason.message : String(e.reason), stack: e.reason e.reason.stack ? e.reason.stack : }); }); } } // 性能插件简化 class PerfPlugin { init(core) { // 立即回捞已经产生的性能条目 const entries [ ...performance.getEntriesByType(paint), ...performance.getEntriesByType(navigation) ]; this.sendPerf(core, entries); // 监听资源加载性能 new PerformanceObserver((list) { const entries list.getEntries(); const resource entries .filter((item) item.initiatorType ! xmlhttprequest item.initiatorType ! fetch) .map((item) ({ name: item.name, duration: item.duration, size: item.transferSize, protocol: item.nextHopProtocol })); core.send(resourcePerf, resource); }).observe({ entryTypes: [resource] }); } sendPerf(core, entries) { const paint {}; entries.forEach((e) { paint[e.name] e.startTime; }); core.send(pagePerf, paint); } } // 初始化示例 const core new TracingCore({ endpoint: /api/tracing, batchSize: 50 }); core.use(error, new ErrorPlugin()); core.use(perf, new PerfPlugin());这个骨架实现了核心管道 异常 性能三个插件路由、请求、曝光、录屏插件按同样的模式扩展即可。它的逻辑是“插件采集、管道汇聚、批量上报”生产环境在这个基础上加上采样控制、隐私脱敏、链路关联就能跑了。代码里有几个地方值得考究getSessionId()实现时可以从sessionStorage读取没有就生成UUID并存进去。上报接口的 endpoint 必须支持跨域或者SDK部署在与业务同域的反代之后否则前端上报请求本身就会触发“跨域失败”得不偿失。生产环境建议加上“事件去重”同一错误堆栈在同一个会话里最多上报3次理由是堆栈相同说明问题相同上报3条足够运维看到趋势再多就是浪费存储。6. 数据量级控制不是什么都该上报前面反复提到采样这里给出一个我在生产环境验证过的数据量概算给初次搭建的团队一个参考数据。假设日活10万概算各模块数据量模块策略单用户日数据量全站日总量行为/埋点全量节流300条3000万条性能数据10%采样5条5万条异常数据全量去重2条20万条请求数据全量去重后100条1000万条资源数据10%采样20条200万条路由数据全量20条200万条曝光数据全量节流100条1000万条录屏5%采样6次会话30000个会话注意表格里的量级最大的还不是录屏而是行为、请求、曝光这类高频事件。这也是为什么每个模块都要在采集端先做一轮“取舍”不能让数据全部进入存储层。否则你的对象存储账单会比业务服务器还贵。很多团队忽略了一个低成本优化上报数据经过的“聚合计算”尽量放在浏览器端完成。比如滚动深度可以只在离开页面时上报一次最大值而不是每秒上报一次资源耗时汇总出 p50、p90、p95 后上报而不是把明细全部回传。这能显著降低后端处理压力也能降低用户隐私泄露风险。7. 开发过程中踩过的坑与经验小结最后分享几个我觉得价值最高的经验都是线上踩过坑才总结出来的。关于错误监控window.onerror拿到的error.stack在不同浏览器里格式不统一生产环境塞进JSON时经常因为特殊字符截断。建议用一个sanitize函数清洗后存入比如把换行符替换成\n转义字符控制单条大小不超过2KB。太长的堆栈信息就用正则截取前几十行保留关键信息即可。关于监控组件自身错误的隔离如果监控SDK本身报错不能影响业务。我的做法是SDK内部所有方法用try...catch包裹并且捕获到的错误不走自己的上报管道而是console.warn提示。因为你上报一个“监控又报错了”的监控对排查业务问题毫无帮助还会占用告警通道。关于监控数据的存储前端监控数据属于典型的“写入多、读取少、查询窗口集中”的数据。存储选型上明细数据用支持列式压缩的存储引擎比如ClickHouse一类能省不少成本聚合报表则直接按小时生成预聚合表查询响应控制在秒级否则运营想看日报时全表扫描会把你卡死。关于告警阈值阈值不能只看平均我见过不少团队设置“异常率超0.5%告警”结果某次故障来时整体用户大面积报错平均下来依然没超阈值。建议同时监控P90和P99P90反映大多数用户的体验P99用于捕获小范围极端问题。另外“环比突增”比“绝对数值”更灵敏同一时段昨天的错误量翻倍往往比当前达到某个固定数值更有预警价值。关于录屏的合规在个人数据保护要求越来越严的今天录屏必须做到“默认脱敏按需开启”。不要一开始就把所有用户都录下来只在需要排查问题时针对特定用户ID或异常会话动态开启录屏。这是功能设计更是责任底线。回看整个WebTracing体系的建设本质上是把“事后救火”变成“事前取证”。性能数据让你知道系统哪里变慢异常数据让你知道哪里报错行为和路由让你知道用户在什么场景下遇到录屏让你像看回放一样确认整条链路。这五个维度叠在一起才算是真正看清了线上真实状态。如果你所在的团队也在搭监控体系我的建议很简单不要追求一次把九个模块全部做齐先做“异常性能请求”这个最小组合跑通链路再逐步加上行为、录屏、曝光。监控体系做得好不好核心不是模块多而是出了故障能不能两小时内讲清楚“用户发生了什么、系统暴露了什么”。