前端监控系统应该如何实现？｜阿里巴巴前端面经解析

60 秒回答模板

我会把前端监控分成采集层、上报层、处理层、分析层和治理层来实现。首先在前端接入一个轻量 SDK，负责采集 JS 运行错误、资源加载错误、Promise 未捕获异常、接口异常、白屏、性能指标、页面访问、点击曝光和关键业务事件。SDK 会统一补充页面 URL、用户匿名标识、会话 ID、设备浏览器、版本号、网络状态、路由信息和时间戳，并做去重、脱敏、采样和缓存。上报通常用 sendBeacon 优先，降级到 fetch 或图片打点，并支持批量、延迟、失败重试和离线缓存，避免影响主流程性能。服务端接收后进入日志队列或流式系统，按项目、版本、页面、错误指纹、用户会话和业务维度聚合，最终落到查询存储和指标平台。告警层会基于错误率、影响用户数、接口失败率、LCP/INP 等核心指标设置阈值、同比环比、突增检测和分级通知。最后还要做隐私合规，不能采集明文手机号、身份证、密码、Token 等敏感信息，用户标识要匿名化，埋点字段要有白名单和权限管控。真正可用的监控不是只有数据看板，而是能回答三个问题：出了什么问题、影响了多少用户、如何快速定位和恢复。

考点 目标与指标设计

主线 前端 SDK 采集

易错点 只回答 window.onerror，没有覆盖性能、行…

深入解析

目标与指标设计

监控体系首先要明确服务对象：研发关注异常堆栈、版本回归和性能瓶颈，产品关注转化漏斗和关键路径，运营关注访问趋势和活动效果，业务负责人关注可用性和收入影响。因此指标要分层设计。技术指标包括 JS 错误率、资源加载失败率、接口失败率、白屏率、首屏耗时、LCP、INP、CLS、长任务、内存占用和页面崩溃。体验指标包括页面打开成功率、首屏可交互时间、弱网成功率、不同设备性能分布。业务指标包括 PV、UV、会话数、按钮点击、曝光、下单转化、支付成功率、关键流程完成率。好的设计不是把所有事件都上报，而是围绕关键链路定义少量稳定、可解释、可告警的指标。

前端 SDK 采集

前端 SDK 是监控的入口，通常需要做到低侵入、低开销、可配置和可扩展。初始化时注入项目 ID、环境、版本号、采样率、用户匿名 ID 和上报地址。SDK 会通过 window.onerror 捕获同步 JS 错误，通过 unhandledrejection 捕获 Promise 未处理异常，通过 addEventListener('error', true) 捕获资源加载失败，通过框架错误边界捕获 React、Vue 等组件异常。对于接口请求，可包装 fetch 和 XMLHttpRequest，记录请求地址、方法、状态码、耗时、错误类型和 Trace ID。对于单页应用，还要监听路由变化，生成页面访问事件和会话上下文。SDK 还需要保护业务代码，采集逻辑失败不能影响页面正常运行。

错误监控实现

错误监控不能只记录一句 message，必须形成可定位的信息结构。一次错误通常包括错误类型、错误消息、堆栈、文件名、行列号、页面 URL、路由、浏览器、操作系统、设备、网络、用户匿名 ID、会话 ID、版本号、构建产物标识和最近行为轨迹。生产环境代码压缩后需要配合 sourcemap 还原原始源码位置，但 sourcemap 不应公开暴露给用户，应上传到内部解析服务。错误去重要做指纹计算，例如按错误类型、归一化后的堆栈、文件路径和函数名聚合，避免同一个错误刷屏。还要区分致命错误、可恢复错误、资源错误、接口错误和业务异常，因为它们的优先级、负责人和修复路径不同。

性能监控实现

性能监控要结合浏览器标准 API 和业务语义。Navigation Timing 可以衡量 DNS、TCP、TLS、请求响应、DOM 解析和 load 阶段；Resource Timing 可以分析静态资源加载耗时和失败；PerformanceObserver 可以采集 LCP、CLS、INP、FID、长任务和布局偏移；自定义打点可以记录首屏渲染、骨架屏消失、接口返回、核心模块渲染完成等业务节点。性能数据要按页面、设备、网络、地区、浏览器、版本分布查看，不能只看平均值，更应关注 P75、P90、P95，因为少数慢用户往往代表真实体验问题。还要把性能指标和版本发布关联，判断某次发布是否导致首屏变慢或交互延迟上升。

行为埋点与业务监控

行为埋点用于还原用户路径和衡量业务目标。常见方式有代码埋点、声明式埋点、可视化埋点和无埋点。代码埋点准确性高，适合支付、提交、授权等关键事件；声明式埋点可通过组件属性配置事件名和参数，降低业务侵入；可视化埋点适合运营快速配置点击和曝光；无埋点可以兜底采集基础点击和页面路径，但语义弱、噪声大。业务监控要关注漏斗：页面访问、按钮点击、表单提交、接口成功、支付完成等步骤是否有异常流失。埋点字段必须稳定，事件命名要规范，参数要有字典和版本管理，否则后期分析会变得不可维护。

上报链路设计

上报要兼顾可靠性和页面性能。普通事件可以进入内存队列，达到数量阈值、时间阈值、页面隐藏或卸载时批量发送。浏览器支持时优先使用 sendBeacon，因为它适合页面退出时异步发送；不支持时可降级为 fetch keepalive、普通 fetch 或图片打点。关键错误可以立即上报，普通行为事件可以延迟批量上报。弱网或离线场景可以写入 localStorage、IndexedDB 或内存缓存，后续恢复再补发，但要设置容量、过期时间和重试次数，避免无限堆积。上报内容要压缩、裁剪和分级，不能把完整大对象、DOM 快照或敏感请求体直接发出去。

采样、限流与数据质量

监控数据量大时必须采样，否则成本和噪声都会失控。采样可以按用户采样、会话采样、事件采样、错误类型采样和动态采样。关键错误、支付失败、白屏、接口 5xx 等高价值事件应尽量全量；普通点击、曝光和性能事件可以按比例采样。限流用于防止单个错误在短时间内大量重复上报，例如同一会话同一错误只报一次，或每分钟最多上报固定数量。数据质量还包括字段校验、时间校准、事件去重、版本归因和异常值过滤。没有治理的数据会造成误判，比如机器人流量、重复上报、测试环境数据混入生产环境都会污染指标。

服务端聚合与存储

服务端通常会提供统一接入网关，做鉴权、限流、字段校验、脱敏和初步清洗，然后写入消息队列或日志管道。实时链路用于告警和分钟级看板，离线链路用于报表、趋势分析和长期留存。错误类数据适合按错误指纹、项目、版本和影响用户数聚合；性能类数据适合按指标分位数、页面和环境维度聚合；行为类数据适合进入事件分析、漏斗分析和路径分析。存储上通常会区分明细日志、聚合指标和索引查询数据，明细保留较短时间，聚合数据保留更久。这样既能定位问题，又能控制成本。

告警与响应闭环

告警不是简单超过阈值就通知，而是要减少误报并提高可行动性。常见规则包括错误率超过阈值、影响用户数超过阈值、接口失败率突增、白屏率升高、核心性能指标劣化、关键业务转化骤降。成熟一些的系统会支持同比环比、发布窗口识别、灰度版本对比、地区或浏览器维度异常检测。告警内容应包含问题摘要、影响范围、开始时间、相关版本、错误样例、用户会话、最近发布记录和负责人。处理流程包括确认、止血、回滚或修复、验证恢复、复盘沉淀。没有闭环的告警只是噪音，有闭环的监控才能提升系统稳定性。

隐私合规与安全

前端监控天然容易接触用户行为和环境信息，因此必须有隐私边界。不能采集密码、验证码、身份证、银行卡、完整手机号、Token、Cookie、精确地址等敏感信息。用户标识应使用匿名 ID 或经过哈希、加盐、映射后的内部 ID，且避免反推出真实身份。请求参数、错误信息和行为属性要经过字段白名单、黑名单和脱敏规则处理。录屏、DOM 快照、输入框内容等高风险能力要默认关闭或严格遮罩，并提供权限控制、留存周期和审计机制。还要区分开发、测试、生产环境，避免测试数据和真实用户数据混杂。

易错点

只回答 window.onerror，没有覆盖性能、行为、上报、采样、聚合和告警闭环。
把监控等同于埋点，忽略错误监控、接口质量和用户体验指标。
只说采集日志，不说明如何定位到源码、版本、用户会话和影响范围。
没有提到采样、限流和去重，导致方案在真实流量下成本不可控。
把所有数据都全量上报，忽略前端性能开销、网络消耗和服务端存储压力。
只设计看板，不设计告警规则、负责人、处理流程和恢复验证。
采集用户输入、Token、Cookie 或完整个人信息，忽略隐私合规风险。
性能监控只看平均值，不看 P75、P90、P95 和不同环境下的分布。
埋点事件命名随意，字段没有规范，后续无法稳定分析和复用。
上报逻辑没有降级、缓存和失败重试，页面关闭或弱网时容易丢数据。

面试官追问

前端如何捕获运行时错误？

同步运行时错误可以通过全局错误监听捕获，Promise 未处理异常通过未处理拒绝监听捕获，框架内部错误通过框架提供的错误边界或错误处理钩子捕获。生产环境还需要结合 sourcemap 还原堆栈，否则压缩后的文件名和行列号很难直接定位源码。

资源加载错误和 JS 错误有什么区别？

JS 错误来自脚本执行过程，通常有错误类型、消息和堆栈。资源加载错误来自 script、link、img、video 等资源请求失败，通常没有标准错误堆栈，需要记录资源 URL、标签类型、页面 URL、状态推断和网络环境。两者的聚合方式和修复负责人也可能不同。

为什么页面卸载时常用 sendBeacon？

因为页面关闭、跳转或进入后台时，普通异步请求可能被浏览器取消。sendBeacon 专门用于在不阻塞页面卸载的情况下发送少量数据，适合监控日志、访问结束事件和批量埋点的最后一次上报。它也要有降级方案，因为不同环境兼容性和请求大小限制不完全一致。

如何判断前端白屏？

常见做法是结合根节点内容、关键 DOM 是否渲染、首屏采样点元素命中、资源和接口状态、框架挂载状态来判断。不能只看 body 是否为空，因为骨架屏、异步渲染和微前端场景都会影响判断。更可靠的方案是业务定义关键渲染完成点，超时未达成再结合 DOM 采样判定。

如何做错误去重和聚合？

可以根据错误类型、归一化后的消息、堆栈关键帧、文件路径、函数名、版本和页面生成错误指纹。归一化很重要，因为纯动态内容会导致同一类错误被拆成大量不同问题。聚合后重点看影响用户数、发生次数、首次出现版本和增长趋势，而不是只看总次数。

埋点怎么保证数据准确？

要从事件规范、字段字典、代码封装、自动校验、灰度验证和数据对账几个方面保证。关键事件最好由业务状态驱动，而不是单纯绑定按钮点击。例如支付成功应以服务端确认或接口成功为准，不能只以上报了点击支付按钮作为成功。

监控数据量很大怎么处理？

前端侧做采样、去重、批量和限流，服务端侧做接入限流、流式清洗、聚合降维和冷热分层存储。高价值事件提高采样率，低价值事件降低采样率。明细数据短期保留用于排障，聚合指标长期保留用于趋势分析。

如何把监控和发布系统结合？

每次构建都写入版本号、构建号和提交信息，SDK 上报时带上这些字段。发布后监控平台按版本对比错误率、白屏率、接口失败率和性能指标。如果新版本指标异常，可以快速定位到发布批次，并结合灰度、回滚或热修复降低影响。