OpenTelemetry Collector 部署方式的选择

快猫运营团队 2024-10-28 11:52:16

OpenTelemetry

OpenTelemetry合并了OpenTracing和OpenCensus项目，提供了一组API和库来标准化遥测数据的采集和传输。OpenTelemetry提供了一个安全，厂商中立的工具，这样就可以按照需要将数据发往不同的后端。

OpenTelemetry项目由如下组件构成：

推动在所有项目中使用一致的规范
基于规范的，包含接口和实现的APIs
不同语言的SDK(APIs的实现)，如 Java, Python, Go, Erlang等
Exporters：可以将数据发往一个选择的后端
Collectors：厂商中立的实现，用于处理和导出遥测数据

OpenTelemetry Collector 部署方式

OpenTelemetry Collector 是一个用于收集、处理和转发遥测数据（如指标、日志和链路追踪）的组件。这个组件内部可以构建指标、日志、链路数据的 Pipeline：

opentelemetry-collector-pipeline

OpenTelemetry Collector 提供了多种部署模式，以适应不同的需求和场景。主要的部署模式如下所示，我们来做简单介绍，并讲解适用场景。

sidecar 模式

opentelemetry-collector-sidecar

即和业务进程放到一个 Pod 内，作为一个 sidecar 容器运行。这种部署模式通常用于业务进程的遥测数据需要特殊处理的场景，例如需要对日志进行脱敏、需要对指标进行聚合、需要对链路追踪数据进行采样等。相当于一个前置处理逻辑。

业务进程的遥测数据直接发到中心化的 Collector 也不是不行，只是所有的特殊逻辑都要放到中心化的 Collector 中，这样会使得 Collector 的配置变得复杂，不易维护。

daemonset 模式

opentelemetry-collector-daemonset

Daemonset 模式是把 OpenTelemetry Collector 部署到集群中的每个节点上，以 Daemonset 的形式运行。这种部署模式通常用于需要在每个节点上收集遥测数据的场景，例如需要收集每个节点上的系统指标、需要收集每个节点上的容器日志等。

Pod 里的业务进程发出的 Traces 数据，可以直接发给本地的 Collector，Collector 再把数据发给中心化的 Collector。这样可以减少网络开销，提高性能。

Pod 里的业务进程也可以直接发给中心化的 Collector，只是这样一来，中心化的 Collector 需要承担非常多的网络连接，攒批动作放到了 Pod 内的进程里，不如把攒批动作放到 Daemonset 内的 Collector 里效果好。

如果你需要采集机器上的系统日志、系统指标，那么 Daemonset 模式是必须的，因为这些数据是在机器上产生的，只有在机器上收集才能收集到。

中心集群模式

opentelemetry-collector-centralized

其实无论如何，一般都有一个中心化的 Collector，用于接收所有的遥测数据，然后再把数据发给后端存储、展示、告警等系统。

中心化的 Collector 通常会有多个实例，用于高可用和负载均衡。中心化的 Collector 通常要承担尾部采样的职能，尾部采样要求同一个 Trace 的多个 Span 都应该发到同一个 Collector 实例上，这样才能保证同一个 Trace 的多个 Span 被聚合在一起一同实施采样逻辑。所以前面的 Collector 在发数据给中心的 Collector 的时候，需要根据 TraceID 做负载均衡，确保相同 TraceID 的 Span 被发到同一个 Collector 实例上。怎么做负载均衡？让前面的 Collector 使用 loadbalancing 的 exporter 来导出数据即可。一个简单的配置样例如下：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  loadbalancing:
    routing_key: "traceID" # 默认不写这个配置就是 traceID
    protocol:
      otlp:
        timeout: 5s
        sending_queue: # 发送队列
          enabled: true
          num_consumers: 50 # 消费者数量
          queue_size: 5000000 # 队列长度
        retry_on_failure:
          enabled: false # 是否重试
        tls:
          insecure: true
    resolver:
      k8s: # k8s service 方式获取pod 的IP 进行负载均衡
        service: otel-collector.observable
    # # static resolver example
    # resolver:
    #   static:
    #     hostnames:
    #       - endpoint: "otel-collector-1:4317"
    #       - endpoint: "otel-collector-2:4317"

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [loadbalancing]