3、数据采集与埋点：如何设计兼容性相关的数据埋点？前端错误监控（Sentry、Fundebug）。后端日志采集与分析。

好，咱们进入第三章。这一章我打算聊聊数据采集和埋点。说白了，就是怎么知道你的软件在用户那边到底跑得怎么样。

很多团队做兼容性测试，测完了就完了。上线后用户报错，才手忙脚乱去查。我个人习惯是，把监控前置。上线第一天，我就得知道哪些浏览器在报错，哪些机型在崩溃。这才是数据驱动的兼容性管理。

3.1 兼容性埋点的核心思路

埋点不是乱埋的。你得想清楚，我要收集什么信息，才能定位兼容性问题。

我一般把兼容性埋点分成三类：

  • 环境信息：浏览器型号、版本、操作系统、设备型号、屏幕分辨率、网络类型。
  • 行为信息：用户操作了什么？点击了哪个按钮？进入了哪个页面？
  • 异常信息：JS报错、资源加载失败、API请求超时、白屏。

这三类信息缺一不可。你想想看，光知道用户报错了，不知道他用的是Chrome还是IE，那排查起来就像大海捞针。

核心原则：埋点数据要能回答三个问题——谁（环境）？做了什么（行为）？出了什么问题（异常）？

3.2 前端错误监控：Sentry 与 Fundebug

前端监控工具，我用得最多的是 Sentry。开源、功能强、社区活跃。Fundebug 我也用过，它对小团队很友好，开箱即用。

先说说 Sentry 怎么接入。其实很简单，几行代码的事。

// 安装
// npm install @sentry/browser

import * as Sentry from '@sentry/browser';

Sentry.init({
  dsn: 'https://你的DSN密钥@oXXXX.ingest.sentry.io/XXXX',
  environment: 'production',
  release: 'v1.0.0',
  // 重点：采集浏览器信息
  beforeSend(event) {
    // 这里可以自定义添加环境信息
    event.extra = {
      ...event.extra,
      userAgent: navigator.userAgent,
      screenWidth: window.screen.width,
      screenHeight: window.screen.height,
      language: navigator.language,
    };
    return event;
  }
});

嗯，这里要注意。Sentry 默认会采集一些环境信息，但不够全。我习惯在 beforeSend 里手动补充。比如屏幕分辨率，有时候兼容性问题就出在分辨率适配上。

Fundebug 的接入更傻瓜化：

// 在 HTML 头部引入
<script src="https://js.fundebug.cn/fundebug.1.10.0.min.js"></script>
<script>
  Fundebug.init({
    apikey: "你的API密钥",
    // 自动采集用户行为
    silentVideo: false,  // 录屏功能，调试神器
  });
</script>

我的经验：Sentry 适合中大型团队，可以自建服务。Fundebug 适合快速验证，录屏功能对复现兼容性问题特别有用。我在一个移动端项目里，就是靠 Fundebug 的录屏，发现某款国产浏览器在渲染 flex 布局时出现了偏移。

3.3 后端日志采集与分析

前端报错只是冰山一角。很多兼容性问题，根源在后端。比如某个老版本浏览器发送的请求头格式不对，导致后端解析失败。

后端日志采集，我推荐结构化日志。别再用 console.log 了，用 JSON 格式输出，方便后续分析。

// Node.js 示例：使用 winston 输出结构化日志
const winston = require('winston');

const logger = winston.createLogger({
  format: winston.format.json(),
  defaultMeta: { service: 'user-service' },
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' }),
  ],
});

// 记录兼容性相关错误
logger.error('API 请求解析失败', {
  userAgent: req.headers['user-agent'],
  requestBody: req.body,
  errorCode: 'PARSE_ERROR',
  browserVersion: extractBrowserVersion(req.headers['user-agent']),
});

为什么要记录 User-Agent？因为你可以通过它反推浏览器版本。我曾经遇到过一个 case，某个接口在 iOS 14 以下的 Safari 上总是报 400 错误。查了日志才发现，是旧版 Safari 发送的 Content-Type 格式不规范。

3.4 知识体系与核心逻辑

说了这么多，我画了一张图，帮你理清整个数据采集的脉络。

兼容性数据采集与埋点核心逻辑 数据源层 环境信息 行为信息 异常信息 采集层 Sentry / Fundebug 结构化日志 自定义埋点 ↓ 数据汇聚与分析 ↓

这张图展示了从数据源到采集工具，再到最终分析的完整链路。说白了，就是先搞清楚要采集什么，再选合适的工具，最后把数据汇总起来做分析。

3.5 避坑指南

我曾经踩过的坑：

  • 埋点太多影响性能：有一次我在每个页面都埋了十几个点，结果页面加载慢了 300ms。后来我改成异步上报，只在关键路径埋点。
  • 忽略隐私合规：采集 User-Agent 没问题，但别采集用户的个人身份信息。GDPR 和《个人信息保护法》可不是闹着玩的。
  • 日志没有分级：所有日志都打 error 级别，结果真正严重的错误被淹没了。我建议至少分 info、warn、error 三级。

3.6 小结

数据采集是兼容性管理的眼睛。没有数据，你就是在黑暗中摸索。前端用 Sentry 或 Fundebug 做错误监控，后端用结构化日志做分析。两者结合，才能形成完整的兼容性视图。

记住一句话：埋点不是目的，分析才是。数据采回来了，得有人看，有人分析，有人推动改进。否则，再漂亮的埋点方案也只是摆设。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →