NingG +

实验平台:日志抽样

1. 背景

现在大量的业务使用 FeatureFlag 和 实验平台,特别是 FeatureFlag ,核心系统使用的地方非常多,导致整个网络的单日 log 流量高达 5TB,而且,还在迅速增加。

log 量大,会影响几个方面:

  1. 存储:影响范围较小,因为磁盘便宜
  2. 网络:大量的带宽被 log 占用,挤占核心数据的带宽,特别是业务高峰期,尤其明显

2. 方案设计

2.1. 业务分析

针对上述 log 存量数据大、增量速度快的情况,考虑进行「日志抽样」+「日志分级」。

不同的场景下,对 log 的要求是不一样的,比如:

因此,从下面个维度,考虑数据抽样业务 log:

  1. 是否抽样
  2. 抽样比例
  3. 特列:白名单流量,全量保存

抽样的业务要求上,要满足:

Note:为了实现一致性抽样效果,要求,抽样的控制参数「集中控制」

2.2. 方案对比

关于抽样的实现:

  1. 基于「桶」的实现:
    1. 优点:现有每层 1000 个桶,方便复用,降低工作量
    2. 缺点:大量实验并行时,单个分组只有 10 个桶时,无法进行 5% 比例的数据抽样;
  2. 单做一层日志抽样逻辑:
    1. 优点:灵活可控、可定制,同时,相对于基于「桶」的改进方案,系统松耦合,更方便定制,可以支持「白名单」流量的全量保存需求
    2. 缺点:需要实现的代码相对较多,大概要多写 100 行代码

结论:

考虑到「逻辑松耦合」,降低开发、维护成本,决定采用「单做一层日志抽样逻辑」。

单做一层日志抽样逻辑」,具体落地细节:

模块 功能点 估时 Status Owner 备注
准备工作 落地方案细节拆解,产出详细设计方案(含交互方案、接口文档)        
Server 修改 model:增加是否抽样、抽样比例参数        
  修改 model 相关的 CRUD service、Controller        
  实验、featureflag 创建逻辑中,设置默认抽样策略参数        
  实验管理后台,增加修改实验的抽样策略的接口        
Client 生效抽样策略        

同类文章:

微信搜索: 公众号 ningg ,即可联系我

Top