详解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。感兴趣的朋友可以参照此文档使用。

来源：https://juejin.cn/post/7178383663095578682