关于go:OpenTelemetry系列-三｜-神秘的采集器-Opentelemetry-Collector

上个篇章中咱们次要介绍了 OpenTelemetry 的客户端的一些数据生成形式，然而客户端的数据最终还是要发送到服务端来进行对立的采集整合，这样能力看到残缺的调用链，metrics 等信息。因而在这个篇章中会次要介绍服务端的采集能力。

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

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

客户端的这种数据上报咱们会统称为 export，同时，实现这些上报的组件咱们对立称作exporters。exporters 会蕴含不同种的数据协定和格局，默认的格局为OTLP。

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

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

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

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

JSON格局应用 proto3 规范定义的 JSON Mapping 来解决 Protobuf 和JSON之间的映射关系。

一般申请 ：在客户端和服务端建设连贯后，客户端能够继续一直的发送申请到服务端，服务端会一一回应。
并发申请：客户端能够在服务端未回应前发送下一个申请，以此进步并发量。

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 来进行。

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是指的接收器，即 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是在 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是指的导出器，即 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是 collector 的扩大，要留神 Extension 不解决 otel 的数据，他负责解决的是一些相似健康检查服务发现，压缩算法等等的非 otel 数据的扩大能力。

一些 Extension 样例：

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

上述的这些配置都是配置的具体数据源或者是插件自身的利用配置，然而实际上的失效与否，应用程序都是在 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 蕴含你想要的 Receiver，Exportor 等，一种终极的计划就是下载源代码，而后配置 golang 的环境，依据本人的需要批改代码并且编译。这种形式可能完满自定义，然而会比拟麻烦，特地是对于非 golang 的开发者，还须要搭建一套 golang 的环境切实是十分麻烦。

OpenTelemetry提供了一种 ocb（OpenTelemetry Collector Builder）的形式来不便大家自定义Collector。感兴趣的敌人能够参照此文档应用。

collector是整个调用链重要的一环，所有的客户端的数据都须要一个对立的采集器来进行接收数据并进行肯定的荡涤工作和转发工作。目前的 OpenTelemetry Collector 做了十分多的工作来放弃兼容性和性能。期待 OpenTelemetry Collector 的 1.0.0 版本可能早日正式公布。

关于go:OpenTelemetry系列-三｜-神秘的采集器-Opentelemetry-Collector

前言

客户端数据上报

OTLP

OTLP/HTTP

OTLP/gRPC

Collector

Collector 简介

Collector 应用

Receiver

Processor

Exportor

Extension

Service

个性化的 Collector

总结