监控SDK设计深度解析

一句话概括

监控 SDK 是前端工程质量的前哨兵，设计核心只有一个约束：它必须”零感知”地运行在宿主应用里——既不能拖慢页面，又要在关键时刻采到数据。好的 SDK 靠三层架构（采集层 → 处理层 → 传输层）+ 数据压缩 + 批量上报 + 插件化，在”采集全面性”与”性能开销”之间取得平衡。

核心知识点

1. 分层架构：采集 / 处理 / 传输三分离

每一层职责单一、可替换，是 SDK 可维护性的根基。核心是”处理层拦截，传输层兜底”：

class MonitorSDK {
  constructor(config) {
    this.collectors = new Map();  // 采集器
    this.processors = [];          // 处理器链（可丢弃数据）
    this.transporter = null;       // 传输器
    this.queue = [];
  }

  report(type, data) {
    let item = { type, data, ts: Date.now() };
    for (const p of this.processors) {
      item = p.process(item);
      if (item === null) return; // 处理器决定丢弃
    }
    this.queue.push(item);
    if (this.queue.length >= 20) this.flush();
  }

  flush() {
    if (!this.queue.length || !this.transporter) return;
    this.transporter.send(this.queue.splice(0));
  }
}

2. 数据压缩：字段缩写 + 精度控制

监控数据 90% 的体积浪费在”又长又重复的字段名”上。字段缩写（字典编码）能把 devicePixelRatio 缩成 dpr，配合精度取整，压缩比轻松 5:1 以上：

const fieldMap = { type: 't', data: 'd', timestamp: 'ts', message: 'msg', devicePixelRatio: 'dpr' };

function compress(obj) {
  if (Array.isArray(obj)) return obj.map(compress);
  if (typeof obj !== 'object' || obj === null) return obj;
  const out = {};
  for (const [k, v] of Object.entries(obj)) {
    out[fieldMap[k] || k] = typeof v === 'number' && Number.isFinite(v)
      ? Math.round(v * 100) / 100 // 精度控制
      : compress(v);
  }
  return out;
}
// devicePixelRatio: 2 → 2；timestamp 保留必要精度即可

3. 批量上报 + 指数退避重试

逐条上报是网络开销灾难；批量 + 定时/阈值触发才是正道。失败重试用指数退避，避免打爆服务器：

class Transporter {
  async send(batch, attempt = 0) {
    try {
      const res = await fetch('/api/monitor', {
        method: 'POST',
        body: JSON.stringify(batch),
        keepalive: attempt === 0,
        headers: { 'Content-Type': 'application/json' },
      });
      if (!res.ok) throw new Error(`HTTP ${res.status}`);
    } catch (e) {
      if (attempt < 3) {
        await new Promise(r => setTimeout(r, 1000 * 2 ** attempt)); // 1s,2s,4s
        return this.send(batch, attempt + 1);
      }
      // 超过重试次数，丢弃并计数
    }
  }
}

4. 采样：不是所有事件都值得全量上报

全量采集的带宽、存储、CPU 开销会反噬宿主应用。按事件类型差异化采样——错误 100%、性能 10%、行为 1%：

// 一致性采样：同一用户要么全采要么全不采，保证用户维度可分析
function shouldSample(userId, rate) {
  const hash = [...userId].reduce((a, c) => (a * 31 + c.charCodeAt(0)) >>> 0, 0);
  return (hash % 1000) / 1000 < rate;
}
shouldSample('user_123', 0.1); // 稳定的布尔结果，而非每次随机

5. 错误隔离：SDK 自己绝不能拖垮主应用

监控 SDK 是”最后一道防线”，自身异常必须被隔离，绝不能 throw 到业务代码：

// 全局错误采集必须包 try-catch，且捕获后不能再次抛出
window.addEventListener('error', (e) => {
  try {
    sdk.report('error', { message: e.message, stack: e.error?.stack });
  } catch (err) {
    // 采集失败就静默，绝不影响主应用
  }
});

其实你每天都在用

1. Google Analytics / 百度统计的 JS 片段：网页里那一小段 <script> 就是监控 SDK——它默默采集 PV、停留时长、点击事件，分批上报，你几乎感觉不到它的存在。
2. 微信 / 支付宝里的”用户体验计划”：那些”是否同意收集使用数据”的弹窗，背后就是 SDK 的行为采集开关，决定你的点击、崩溃要不要被采样上报。
3. App 崩溃后弹的”是否反馈问题”：点击后上传的那份日志，就是 SDK 采集 → 压缩 → 上报的完整链路。
4. 网页首屏加载的那个”秒开”指标：LCP、FCP 这些 Core Web Vitals 数据，都是 PerformanceObserver 采集器自动埋进去的，你没写一行代码。
5. 广告系统按曝光计费：每个广告位”被谁看到、看了多久”都要靠监控 SDK 采集上报，数据不准直接等于钱算错。

常见误解（FAQ）

❌ 误区一：监控 SDK 就是 try-catch 包一下再 console.log。 错误。console.log 不持久化、不远程、不可分级。真正的 SDK 是一套完整的采集→过滤→采样→压缩→批量→重试的流水线，window.onerror 只是采集层的冰山一角。

❌ 误区二：采集越多越好，全量采集最保险。 错误。全量采集会带来带宽、存储、CPU 三重开销，甚至反过来导致低端设备卡顿。正确做法是差异化采样：关键错误 100%，性能 10-20%，行为 1-5%，并支持服务端用 Feature Flag 动态调整。

❌ 误区三：SDK 采集逻辑不可能影响主应用性能。 错误。JSON.stringify、getEntriesByType('resource') 遍历几百条记录、在高频事件里采集，都是实打实的 CPU 开销。必须设置 CPU 时间预算、队列上限，并用 requestIdleCallback 调度采集，低端设备还要主动降级。

❌ 误区四：网络断了就断了吧，重试反而浪费。 错误。断网是弱网用户的常态，直接丢弃会导致数据永久缺失。正确做法是：先落 IndexedDB 持久化，网络恢复后按指数退避重试补传，pagehide 时用 sendBeacon 兜底。

一句话总结

监控 SDK 的成败，不在采了多少数据，而在它是否做到”需要时一定有数据、平时绝无存在感”——用分层架构、采样、压缩和错误隔离，把性能开销压到几乎为零。