以每周一个节点，记录知识点。
2024-10-07~13
OpenTelemetry 采样
分布式追踪可以为用户描述一次请求所经历的过程，形成一张调用时序图，我们称这次调用过程调用链路为 Trace。而 Trace 由每个服务或者说服务处理一个请求的过程组成，这些过程称为 Span。
下面是减少 Trace 数量的现成手段
头部采样
当请求抵达整个链路中第一个服务时，这个服务为这次请求生成一个独一无二的 Trace ID，以及其他的标记位，这些信息会贯穿整次请求。标记位中包含采样标记位，由服务依照一定的概率或者规则生成，代表要采样或者不采样。Trace ID 、标记位和其他上下文信息通过 RPC Header、Metadata 等方式传播给后续的服务，后续服务遵循第一个服务的采样决定，也随之采样上报或不上报。
特点：
- 它是由头部服务，或者说第一个产生的 Span 决策的，传播至后续的 Span，整个采样决策发生客户端 SDK 层面，仅有少量被采样的数据允许被发送出去，因此，后续的处理流程中也只有少量数据流转、存储、展示。
问题：
- 第一个 Span 的视野非常有限，无法预知未来会发生什么，也就无法依照整个请求是否有错误、是否执行时间过长来做决策。
尾部采样
为了解决这些问题，我们也可以把所有数据都上报，交由一个中间平台暂存、清洗，再决定保留还是丢弃整条 Trace。如下图所示，当请求抵达时，每个服务都将他自身产生的 Span 发送至 OpenTelemetry Collector，Collector 上的尾部采样组件在接收到第一个 Span 后，会等待一段时间（如 5 秒）以继续收集来自其他服务的、具有相同 Trace ID 的 Span。等待结束后，大量 Span 按照 Trace ID 归类，然后对同一个 Trace ID 下的 Span 进行遍历，以检查其中是否包含错误信息、累计耗时是否超过阈值等，有依据地筛选高价值的 Trace 进入后续的流程。
特点：
- 持久化的数据有依据、有规律、有价值；
- 减少了展示有价值数据所需的成本，例如存储资源，并且对提高查询速度也有帮助。 问题：
- 由于需要承载大量临时数据，所以对基础设施要求很高。
- 多个 Collector 节点, 需要增加一个负载均衡，依照TraceID 来转发Trace 数据到 Collector 节点上。