前端一面：前端监控与埋点系统设计

越来越多的一面/二面会问“你们前端是怎么做监控和埋点的”，这题一方面考察工程经验，一方面看你对“前端在线上是怎么活着的”有没有思考。这一篇给一个最小可行的监控/埋点系统设计视角。

一个常见的前端监控/埋点系统，至少要覆盖几类数据：

  • 性能：白屏时间、首屏渲染时间、TTFB、资源加载耗时等；
  • 错误：运行时错误（onerror）、未处理的 Promise 拒绝（onunhandledrejection）、接口错误；
  • 行为：PV/UV、页面停留时长、按钮/链接点击、关键路径（如下单流程）转化情况；
  • 环境：浏览器/操作系统版本、设备信息、网络类型等。

一面回答时，先把这几类“我们关心的指标”讲清楚，再谈如何采集和上报。

采集层常见的两种方式：

  • 显式埋点
    • 在业务代码中手动调用埋点方法：
1tracker.track("button_click", {
2  page: "/checkout",
3  button: "submit_order"
4});

  • 适合关键业务事件（如注册成功、下单完成）；

  • 需要定义统一的事件名和参数规范，避免“同一事件多个名字”。

  • 隐式采集 / 全局 Hook

    • 性能：使用 Performance API、PerformanceObserver；
    • 错误：window.onerror、window.onunhandledrejection；
    • 路由：在路由变化处统一记录 PV/路径变更。

一个简单的 SDK 架构：

  • 提供 track(eventName, payload) 方法供业务调用；
  • 在初始化时挂全局监听器采集性能和错误；
  • 内部有一层队列和批量上报逻辑。

数据采集到浏览器端之后，需要考虑如何上报到后端：

  • 上报方式

    • navigator.sendBeacon：适合在页面卸载时发送（如离开页面的最后一批数据）；
    • fetch/XHR：常规上报方式；
    • 图片打点（new Image().src = url）：早期常用，兼容性好但表达能力有限。

  • 上报策略

    • 实时 vs 批量：
      • 实时：每条事件立即上报，简单但请求数多；
      • 批量：将多条事件缓存在内存中，达到一定数量或时间间隔再上报；
    • 可靠性：
      • 页签关闭时使用 sendBeacon 做兜底；
      • 对失败的上报可以简单重试或缓存到 localStorage，再在下一次会话中 flush。

在一面答题时，可以强调你会“在不明显影响业务性能的前提下，上报够用的数据”，而不是把浏览器当日志服务器。

前端上报的数据需要有后端存储和分析支持，一般包括：

  • 接收埋点数据的 API 网关/收集服务；
  • 数据落地（日志系统、时序数据库、OLAP 等）；
  • 可视化看板（如 Grafana/自研控制台）：
    • 展示 PV/UV、转化漏斗、错误趋势、性能指标；
    • 支持过滤/分组（按版本、地区、终端类型等）。

一面通常不会深入后端实现细节，只要你说明“会有一条从前端 SDK → 接收端 → 存储 → 可视化/告警的路径”，就已经表现出全局视角。

参考答案结构：

  • 先概括目标：监控性能、错误和关键业务行为；
  • 再描述实现大致分层：
    • 页面里引入一个轻量 SDK，提供 track 方法；
    • SDK 在初始化时挂全局错误/性能监听；
    • 收集到的数据缓存在内存队列中，按一定策略批量上报到后端；
    • 后端有对应的分析/可视化平台，用来做日报、告警和排查。

如果有具体指标或告警经验，可以顺带提一下，比如“接口错误率超过某个阈值会发告警”。

参考答案要点：

  • 使用 window.onerror 捕获未被处理的同步错误，使用 window.onunhandledrejection 捕获未处理的 Promise 拒绝；
  • 在框架层（如 React 的 Error Boundary）捕获组件渲染中的错误；
  • 将错误信息（消息、堆栈、URL、用户环境信息等）打包，通过埋点 SDK 上报；
  • 在后端按错误类型/路径/版本做聚合，方便定位和回滚。

这题可以和前一篇《错误处理与全局异常捕获》呼应。

参考答案要点：

  • 埋点 SDK 本身要尽量小，延迟加载，不阻塞主业务逻辑；
  • 使用批量上报和适当的降采样策略，避免过于频繁的网络请求；
  • 尽量使用浏览器原生 API（如 PerformanceObserver）而不是频繁轮询；
  • 在产品/数据侧评估哪些指标是“必须的”，避免采集大量不必要的数据。

表现出你有“监控系统也要被监控”的意识，会是这一题的加分项。