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 / Web | android_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.2k | 45 | 210 |
| Modifier触发事件 | 1:10 | 230 | 78 | 340 |
| Modifier结果上报 | 1:100 | 24 | 110 | 560 |
| 异常日志 | 全采样 | 15 | 320 | 1200 |
3.5 异常解释
⚠ 采样频率漂移:当客户端本地时钟与服务器不一致时,自适应采样策略可能错误地降低或提高采样率,导致预期事件数失真。解决方案:在SDK中增加NTP时间同步,并上报客户端时钟偏移量。
⚠ 埋点碰撞:同一事件被两个不同的采集模块同时捕获,导致重复计数。检查
eventId去重逻辑是否在服务端聚合层实现。
3.6 业务动作
- 调整采样频率:当丢点率>0.5%时,降低该埋点位置的采样频率(如从1:10改为1:50),并观察延迟变化。
- 补充埋点:如果看板中发现“Modifier触发事件”量远低于预期,需检查App内生命周期钩子是否覆盖全部Modifier入口。
- 配置下发:通过远程配置平台推送
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图中的“采样率过滤”节点后新增“降级检测”菱形分支。
3.8 与看板指标联动
图框内的“采样过滤”节点直接影响看板中“采集覆盖率”和“丢点率”的计算。当采样率设置为1:10时,预期事件数应放大10倍;若实际上报量远小于预期×0.1,则提示埋点遗漏或缓存满丢失。看板应提供“采样率版本对比”功能,方便复盘时回放不同采样策略下的指标变化。