采样方案

[zzhutianyu]

为什么需要采样

• 在生产系统中，调用是非常频繁的这就导致了在高频系统中，会产生非常多的span，这样就会给整个链路和存储带来压力
• 而一些系统又不是高频系统，所以可以存储所有的span
  合理的采样可以极大降低成本和整体系统的压力
  所以我们对于span的产生需要进行合理采样

怎么进行采样

目前主要有两种采样形式

• 一种是基于头部的采样
  也就是在根链路的产生的时候来进行采样策略判断是否进行采样，目前主流的分布式跟踪框架都主要使用这一方式，虽然头部采样的形式能比较好降低span的产生，但是在实际生产中，大部分都是正常的链路，少部分才是异常链路，采样策略可能会将错误链路给命中，导致异常被遗漏。基于头部的采样，是需要在TRACE-SDK进行配置，它直接在应用程序生效，所以管控这个配置是有成本的。如果在微服务更个服务比较独立的时候还存在一些服务开启了采样，一些服务没有开启采样，这就会导致某几个未开启服务产生大量span对整个上下游服务进行了传播，导致后端服务压力大增。
• 基于尾部的采样
  基于尾部的采样能很好的将异常的链路进行保留，而且基于尾部的采样是允许在接收服务中的，这就意味着，应用程序只需要关注上报服务是谁，而不在需要关注额外的配置和配置变更。但是尾部采样也存在的一些问题，就是当span跨度过大时，进行的采样的时候，可能会遗漏部分长尾span.而且过大的全量流量对于上报服务来说也有着一定的压力考验。

基于头部的采样

基于头部的采样是现在主流分布式跟踪的框架进行采样的主要模式。在otlp当中就原生实现了采样的配置，并支持了一些原生的采样策略。

• ALWAYS_ON 总是产生
• ALWAYS_OFF 不产生
• ALWAYS_PARENT 信任父span的采样结果
• Probability 概率采样
  这些都是配置的头部采样的配置。
  如果支持头部采样，我们还需要实现能够让用户进行应用运行时的一些配置的修改。
• 采样配置
  • 采样策略
  • 采样精度
• 染色配置
  • 匹配字段
  • 目标值

平台SDK-api配置拉取或者直接api获取配置

主要需要后端平台侧提供配置获取接口
用户需要在应用层或者平台SDK实现以下功能

• 定时的配置拉取
• 配置刷新
  

用户配置文件读取

用户需要自行手动或者自动化程序去修改对应的配置文件例如yaml文件等进行相应的配置文件修改，应用需要支持以下功能

• 动态文件配置读取更新

用户自定义配置服务更新

和第一类类似，主要是业务侧自己的配置服务或者其他类似服务可以进行配置的下发或者拉取

基于尾部的采样

尾部采样主要是在上报之后由接收侧服务进行采样，这样做需要进行一定数据的缓存，我们可以在接收端做，也可以在链路中做，但是最主要解决的问题，是需要相同trace_id的span进行缓存主要有以下方式

Trace-Lb

集群一致性转发