OpenTelemetry系列 （三）｜ 神秘的采集器 - Opentelemetry Collector

前言

上个篇章中我们主要介绍了OpenTelemetry的客户端的一些数据生成方式，但是客户端的数据最终还是要发送到服务端来进行统一的采集整合，这样才能看到完整的调用链，metrics等信息。因此在这个篇章中会主要介绍服务端的采集能力。

客户端数据上报

客户端会根据一定的规则生成调用链，metrics，logs等信息，然后就会将其推送到服务器远端。一般来说OpenTelemetry的服务端客户端传递数据的请求协议标准是Http和Grpc协议，在各语言的sdk以及服务端实现中都应该包含这两个数据协议的的实现。

按照常理来说调用链等数据的数据量极大，因此在客户端就会有一些类似于Batch的操作选项，此选项会将多个Span信息整合到一起一并发送，以减小网络端的损耗。

客户端的这种数据上报我们会统称为export，同时，实现这些上报的组件我们统一称作exporters。exporters会包含不同种的数据协议和格式，默认的格式为OTLP。

OTLP

OTLP是指OpenTelemetry Protocol，即OpenTelemetry数据协议。OTLP规范规定了客户端和服务采集端之间的遥测数据的编码,传输和投送。

OTLP在实现上分为OTLP/gRPC和OTLP/HTTP。

OTLP/HTTP

OTLP/HTTP在数据传输的时候支持两种模式：二进制和json

二进制使用proto3编码标准，且必须在请求头中标注Content-Type: application/x-protobuf

JSON格式使用proto3标准定义的JSON Mapping来处理Protobuf和JSON之间的映射关系。

OTLP/gRPC

普通请求：在客户端和服务端建立连接后，客户端可以持续不断的发送请求到服务端，服务端会一一回应。
并发请求：客户端可以在服务端未回应前发送下一个请求，以此提高并发量。

Collector

Collector简介

OpenTelemetry提供了开源的Collector来进行客户端数据的上报采集，处理和输出。otel collector是一个支持了多种协议，多种数据源的“万能”采集器。可以说是你能想到的很多数据源他都能够直接支持。

otel collector使用golang实现，到文章目前编写的时候已经发布了1.0.0的rc版本。Collector区分为了两个项目opentelemetry-collector，opentelemetry-collector-contrib。opentelemetry-collector是核心项目，实现了collector的基本机制以及一些基础的组件，而opentelemetry-collector-contrib则会有大量的组件，而这些组件由于不同原因不便被直接集成到核心的collector中，因此单独构建了一个项目来集成这些组件。我们后续的collector功能介绍和验证都会基于opentelemetry-collector-contrib来进行。

Collector使用

otel collector的组成是很清晰的，分为：

• Receiver
• Processor
• Exporter
• Extension
• Service

整个配置文件的样例如下：

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  jaeger:
    endpoint: localhost:14250
    tls:
      insecure: true
  logging:
    loglevel: debug

processors:
  batch:

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [pprof, zpages, health_check]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [jaeger, logging]
      processors: [batch]

这个配置是我本地测试时使用的一个配置，这个配置很简单，接收otlp http/grpc的上报数据，进行batch处理，然后输出到控制台日志和jaeger中。我们将各项数据源和插件配置完成后，在流水线中配置使用的数据源和插件。

Receiver

Receiver是指的接收器，即collector接收的数据源的形式。Receiver可以支持多个数据源，也能支持pull和push两种模式。

receivers:
  # Data sources: logs
  fluentforward:
    endpoint: 0.0.0.0:8006

  # Data sources: metrics
  hostmetrics:
    scrapers:
      cpu:
      disk:
      filesystem:
      load:
      memory:
      network:
      process:
      processes:
      swap:

  # Data sources: traces
  jaeger:
    protocols:
      grpc:
      thrift_binary:
      thrift_compact:
      thrift_http:

  # Data sources: traces
  kafka:
    protocol_version: 2.0.0

  # Data sources: traces, metrics
  opencensus:

  # Data sources: traces, metrics, logs
  otlp:
    protocols:
      grpc:
      http:

  # Data sources: metrics
  prometheus:
    config:
      scrape_configs:
        - job_name: "otel-collector"
          scrape_interval: 5s
          static_configs:
            - targets: ["localhost:8888"]

  # Data sources: traces
  zipkin:

上述是一个receiver的样例，里面展示了多种不同的接收数据源的配置。

Processor

Processor是在Receiver和Exportor之间执行的类似于处理数据的插件。Processor可以配置多个并且根据在配置中pipeline的顺序，依次执行。

以下是一些Processor的配置样例：

processors:
  # Data sources: traces
  attributes:
    actions:
      - key: environment
        value: production
        action: insert
      - key: db.statement
        action: delete
      - key: email
        action: hash

  # Data sources: traces, metrics, logs
  batch:

  # Data sources: metrics
  filter:
    metrics:
      include:
        match_type: regexp
        metric_names:
          - prefix/.*
          - prefix_.*

  # Data sources: traces, metrics, logs
  memory_limiter:
    check_interval: 5s
    limit_mib: 4000
    spike_limit_mib: 500

  # Data sources: traces
  resource:
    attributes:
      - key: cloud.zone
        value: "zone-1"
        action: upsert
      - key: k8s.cluster.name
        from_attribute: k8s-cluster
        action: insert
      - key: redundant-attribute
        action: delete

  # Data sources: traces
  probabilistic_sampler:
    hash_seed: 22
    sampling_percentage: 15

  # Data sources: traces
  span:
    name:
      to_attributes:
        rules:
          - ^\/api\/v1\/document\/(?P<documentId>.*)\/update$
      from_attributes: ["db.svc", "operation"]
      separator: "::"

Exportor

Exportor是指的导出器，即collector输出的数据源的形式。Exportor可以支持多个数据源，也能支持pull和push两种模式。

以下是一些Exportor的样例：

exporters:
  # Data sources: traces, metrics, logs
  file:
    path: ./filename.json

  # Data sources: traces
  jaeger:
    endpoint: "jaeger-all-in-one:14250"
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Data sources: traces
  kafka:
    protocol_version: 2.0.0

  # Data sources: traces, metrics, logs
  logging:
    loglevel: debug

  # Data sources: traces, metrics
  opencensus:
    endpoint: "otelcol2:55678"

  # Data sources: traces, metrics, logs
  otlp:
    endpoint: otelcol2:4317
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

  # Data sources: traces, metrics
  otlphttp:
    endpoint: https://example.com:4318/v1/traces

  # Data sources: metrics
  prometheus:
    endpoint: "prometheus:8889"
    namespace: "default"

  # Data sources: metrics
  prometheusremotewrite:
    endpoint: "http://some.url:9411/api/prom/push"
    # For official Prometheus (e.g. running via Docker)
    # endpoint: 'http://prometheus:9090/api/v1/write'
    # tls:
    #   insecure: true

  # Data sources: traces
  zipkin:
    endpoint: "http://localhost:9411/api/v2/spans"

Extension

Extension是collector的扩展，要注意Extension不处理otel的数据，他负责处理的是一些类似健康检查服务发现，压缩算法等等的非otel数据的扩展能力。

一些Extension样例：

extensions:
  health_check:
  pprof:
  zpages:
  memory_ballast:
    size_mib: 512

Service

上述的这些配置都是配置的具体数据源或者是插件本身的应用配置，但是实际上的生效与否，使用顺序都是在Service中配置。主要包含如下几项：

• extensions
• pipelines
• telemetry

Extensions是以数组的形式配置的，不区分先后顺序：

service:
  extensions: [health_check, pprof, zpages]

pipelines配置区分trace，metrics和logs，每一项都可以配置单独的receivers，processors和exportors，均是以数组的形式配置，其中processors的数组配置需要按照想要的执行顺序来配置，而其他的则无关顺序。

service:
  pipelines:
    metrics:
      receivers: [opencensus, prometheus]
      exporters: [opencensus, prometheus]
    traces:
      receivers: [opencensus, jaeger]
      processors: [batch]
      exporters: [opencensus, zipkin]

telemetry配置的是collector本身的配置，主要是log和metrics，下列配置就是配置了collector自身的日志级别和metrics的输出地址：

service:
  telemetry:
    logs:
      level: debug
      initial_fields:
        service: my-instance
    metrics:
      level: detailed
      address: 0.0.0.0:8888

个性化的Collector

如果你想要自定义个性化的Collector包含你想要的Receiver，Exportor等，一种终极的方案就是下载源代码，然后配置golang的环境，根据自己的需求修改代码并且编译。这种方式能够完美自定义，但是会比较麻烦，特别是对于非golang的开发者，还需要搭建一套golang的环境实在是非常麻烦。

OpenTelemetry提供了一种ocb（OpenTelemetry Collector Builder）的方式来方便大家自定义Collector。感兴趣的朋友可以参照此文档使用。

总结

collector是整个调用链重要的一环，所有的客户端的数据都需要一个统一的采集器来进行接收数据并进行一定的清洗工作和转发工作。目前的OpenTelemetry Collector做了非常多的工作来保持兼容性和性能。期待OpenTelemetry Collector的1.0.0版本能够早日正式发布。