实验平台：日志抽样
2017-07-08
1. 背景
现在大量的业务使用 FeatureFlag 和 实验平台，特别是 FeatureFlag ，核心系统使用的地方非常多，导致整个网络的单日 log 流量高达 5TB，而且，还在迅速增加。
log 量大，会影响几个方面：
- 存储：影响范围较小，因为磁盘便宜
- 网络：大量的带宽被 log 占用，挤占核心数据的带宽，特别是业务高峰期，尤其明显
2. 方案设计
2.1. 业务分析
针对上述 log 存量数据大、增量速度快的情况，考虑进行「日志抽样」+「日志分级」。
不同的场景下，对 log 的要求是不一样的，比如：
- 实验平台：业务方使用的较少，但要求日志不可丢失，不建议抽样
- FeatureFlag 功能灰度发布控制：业务方使用范围广，但，大多只观察流量的调配比例和效果，建议抽样
因此，从下面个维度，考虑数据抽样业务 log：
- 是否抽样
- 抽样比例
- 特列：白名单流量，全量保存
抽样的业务要求上，要满足：
- 一致性抽样：相同的流量，要么都抽样，要么都不抽样
Note：为了实现一致性抽样效果，要求，抽样的控制参数「集中控制」
2.2. 方案对比
关于抽样的实现：
- 基于「桶」的实现：
- 优点：现有每层 1000 个桶，方便复用，降低工作量
- 缺点：大量实验并行时，单个分组只有 10 个桶时，无法进行 5% 比例的数据抽样；
- 单做一层日志抽样逻辑：
- 优点：灵活可控、可定制，同时，相对于基于「桶」的改进方案，系统松耦合，更方便定制，可以支持「白名单」流量的全量保存需求
- 缺点：需要实现的代码相对较多，大概要多写 100 行代码
结论：
考虑到「逻辑松耦合」，降低开发、维护成本，决定采用「单做一层日志抽样逻辑」。
「单做一层日志抽样逻辑」，具体落地细节：
| 模块 | 功能点 | 估时 | Status | Owner | 备注 |
|---|---|---|---|---|---|
| 准备工作 | 落地方案细节拆解，产出详细设计方案（含交互方案、接口文档） | ||||
| Server | 修改 model：增加是否抽样、抽样比例参数 | ||||
| 修改 model 相关的 CRUD service、Controller | |||||
| 实验、featureflag 创建逻辑中，设置默认抽样策略参数 | |||||
| 实验管理后台，增加修改实验的抽样策略的接口 | |||||
| Client | 生效抽样策略 |
原文地址：https://ningg.top/experiment-series-log-sample/