高负载下OpenTelemetry Collector与Zipkin弹性扩容方案咨询

整体分层架构逻辑 #

整套扩容体系拆分为两层独立的负载均衡环节，分别匹配不同环节的一致性要求，避免耦合设计带来的复杂度：

• 第一层：业务应用侧到多Collector实例的流量均衡，核心目标是把遥测采集请求均匀拆分到无状态的Collector集群
• 第二层：多Collector实例到多Zipkin后端的流量均衡，核心目标是保证同一条Trace的所有片段路由到同一个Zipkin实例，避免链路数据分散无法聚合

业务应用接入多Collector集群的流量实现路径 #

针对不同的业务改造成本和部署环境，可落地三种零特殊依赖的均衡方案，不存在必须自研组件的门槛：

• 静态配置直连：业务应用侧在OTLP导出器的配置项中直接录入多个Collector的接入地址，SDK内置的轮询逻辑会自动把流量拆分到不同Collector，适合Collector实例数量少、地址长期固定的小规模场景
• 服务发现自动感知：容器化部署场景下，把Collector集群的接入端点注册到内部服务发现组件（如K8s Service、Consul），业务应用SDK从服务发现组件拉取可用的Collector实例列表，自动做健康检查和故障切换，Collector扩缩容时应用侧完全无感知
• 前置负载层兜底：如果业务侧无法改造SDK配置，直接在Collector集群最前端部署标准四层/七层负载均衡组件，所有业务应用统一指向负载均衡的固定接入地址，由负载均衡按连接数、请求数把流量分发到后端Collector实例

注意：这一层的流量分发不需要做Trace ID粘性路由，任意遥测数据片段被分配到任意Collector实例都不影响最终的Trace聚合效果，可最大程度简化接入层配置、提升流量均匀度。

Collector集群到Zipkin后端的扩容实现 #

直接采用OpenTelemetry Collector Contrib内置的Trace ID感知负载均衡导出器即可实现该环节的扩容能力，组件会基于Trace ID做一致性哈希路由，保证同一条Trace的所有片段都被分发到同一个Zipkin实例，避免出现链路数据分散、查询不全的问题。参考配置如下：

loadbalancing:
  protocol:
    otlp:
      timeout: 1s
      insecure: true
  resolver:
    static:
      hostnames:
      - localhost:55690
      - localhost:55700
      - localhost:55710
      - localhost:55720

落地过程中的常见误区 #

• 不需要在Collector集群内部新增独立的流量分发组件，Collector本身是完全无状态的，接入层完成流量拆分后，任意Collector实例都可以处理任意来源的遥测数据
• 不要把应用接入层的流量均衡和Collector到Zipkin层的均衡逻辑混淆，前者不需要会话粘性，后者必须开启Trace ID感知能力，搞反会直接导致扩容后出现查询故障
• Collector侧的负载均衡导出器如果未开启Trace ID感知能力，水平扩容Zipkin实例后会出现同一条Trace被拆到不同实例的问题，无法完成完整链路聚合

内容的提问来源于stack exchange，提问作者Alexander Kazantsev