3 采集链路搭建:数据流图、埋点位置、采样频率

3.1 指标定义

指标定义算式
采集覆盖率上报事件数 / 预期产生事件数 × 100%上报事件数 / 预期事件数 * 100
采样延迟 P50/P99从事件发生到服务端收到的时间分位数从埋点时间戳差计算
丢点率丢失事件数 / 应上报事件数 × 100%1 - (实际收到数 / 预期数)
采样命中率实际采样数 / 采样策略应采样数 × 100%用于评估采样规则执行正确性

3.2 数据口径

  • 有效事件:事件携带完整Modifier字段(sessionId、durationMs、modifierType、deviceInfo)且时间戳与服务器时间差≤5分钟。
  • 预期事件数:基于用户行为日志(如页面PV、点击次数)乘以Modifier触发概率计算,用于修正采样后的分母。
  • 采样频率:以“每X条事件采样1条”或“每秒最多N条”两种模式记录,统一折算为采样率 = 采样数量 / 总事件数量。

3.3 维度拆解

维度说明常见取值
端侧Android / iOS / Webandroid_v3.2, ios_v2.8, web_sdk_1.5
埋点类型PV埋点、点击埋点、自定义事件modifier_start, modifier_complete, modifier_error
采样策略固定采样、自适应采样、全采样1:10, 1:100, 全量
上报渠道HTTP批量上报、WebSocket实时上报batch_upload, realtime_stream

3.4 看板结构

看板分为三层:顶层卡片展示采集链路健康度(覆盖率、丢点率),中层为埋点位置-采样频率对应矩阵表,底层为链路延迟瀑布图。本节重点搭建中层矩阵,结构如下:

埋点位置采样频率最近5分钟上报量延迟P50/ms延迟P99/ms
App启动全采样1.2k45210
Modifier触发事件1:1023078340
Modifier结果上报1:10024110560
异常日志全采样153201200

3.5 异常解释

⚠ 采样频率漂移:当客户端本地时钟与服务器不一致时,自适应采样策略可能错误地降低或提高采样率,导致预期事件数失真。解决方案:在SDK中增加NTP时间同步,并上报客户端时钟偏移量。
⚠ 埋点碰撞:同一事件被两个不同的采集模块同时捕获,导致重复计数。检查eventId去重逻辑是否在服务端聚合层实现。

3.6 业务动作

  1. 调整采样频率:当丢点率>0.5%时,降低该埋点位置的采样频率(如从1:10改为1:50),并观察延迟变化。
  2. 补充埋点:如果看板中发现“Modifier触发事件”量远低于预期,需检查App内生命周期钩子是否覆盖全部Modifier入口。
  3. 配置下发:通过远程配置平台推送sampling_config.json到客户端。
{
  "modifier_trigger": {
    "strategy": "fixed_rate",
    "rate": 0.1,          // 1:10
    "max_per_second": 50
  },
  "modifier_result": {
    "strategy": "adaptive",
    "target_delay_ms": 200,
    "min_rate": 0.01,
    "max_rate": 0.5
  }
}

3.7 复盘分析

在一次大促流量峰值复盘案例中,发现Modifier结果上报延迟P99从300ms飙升到1200ms。通过看板下钻到“采样频率”维度,发现自适应采样策略误将全量采样放大,导致后端背压。复盘动作:

  • 将自适应采样上限设为0.2(即1:5),并加入客户端本地节流。
  • 增加链路中熔断器:当过去1分钟平均延迟>500ms时自动降级为1:100。
  • 在SVG图中的“采样率过滤”节点后新增“降级检测”菱形分支。
采集链路数据流图(埋点位置 & 采样频率) 用户操作 SDK埋点 本地缓存 采样过滤 批量上报 服务端接收 丢弃 采样频率配置示例 固定采样:1:10 → rate=0.1 自适应采样:target_delay_ms=200 全采样:rate=1.0(仅用于关键埋点)

3.8 与看板指标联动

图框内的“采样过滤”节点直接影响看板中“采集覆盖率”和“丢点率”的计算。当采样率设置为1:10时,预期事件数应放大10倍;若实际上报量远小于预期×0.1,则提示埋点遗漏或缓存满丢失。看板应提供“采样率版本对比”功能,方便复盘时回放不同采样策略下的指标变化。