快捷導(dǎo)航

詳解Opentelemetry Collector采集器

更新時間：2022年12月20日 11:20:08 作者：騎牛上青山

這篇文章主要為大家介紹了Opentelemetry Collector神秘的采集器詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

上個篇章中我們主要介紹了OpenTelemetry的客戶端的一些數(shù)據(jù)生成方式，但是客戶端的數(shù)據(jù)最終還是要發(fā)送到服務(wù)端來進行統(tǒng)一的采集整合，這樣才能看到完整的調(diào)用鏈，metrics等信息。因此在這個篇章中會主要介紹服務(wù)端的采集能力。

客戶端數(shù)據(jù)上報

客戶端會根據(jù)一定的規(guī)則生成調(diào)用鏈，metrics，logs等信息，然后就會將其推送到服務(wù)器遠端。一般來說OpenTelemetry的服務(wù)端客戶端傳遞數(shù)據(jù)的請求協(xié)議標(biāo)準(zhǔn)是Http和Grpc協(xié)議，在各語言的sdk以及服務(wù)端實現(xiàn)中都應(yīng)該包含這兩個數(shù)據(jù)協(xié)議的的實現(xiàn)。

按照常理來說調(diào)用鏈等數(shù)據(jù)的數(shù)據(jù)量極大，因此在客戶端就會有一些類似于Batch的操作選項，此選項會將多個Span信息整合到一起一并發(fā)送，以減小網(wǎng)絡(luò)端的損耗。

客戶端的這種數(shù)據(jù)上報我們會統(tǒng)稱為export，同時，實現(xiàn)這些上報的組件我們統(tǒng)一稱作exporters。exporters會包含不同種的數(shù)據(jù)協(xié)議和格式，默認的格式為OTLP。

OTLP

OTLP是指OpenTelemetry Protocol，即OpenTelemetry數(shù)據(jù)協(xié)議。OTLP規(guī)范規(guī)定了客戶端和服務(wù)采集端之間的遙測數(shù)據(jù)的編碼,傳輸和投送。

OTLP在實現(xiàn)上分為OTLP/gRPC和OTLP/HTTP。

OTLP/HTTP

OTLP/HTTP在數(shù)據(jù)傳輸?shù)臅r候支持兩種模式：二進制和json

二進制使用proto3編碼標(biāo)準(zhǔn)，且必須在請求頭中標(biāo)注Content-Type: application/x-protobuf

JSON格式使用proto3標(biāo)準(zhǔn)定義的JSON Mapping來處理Protobuf和JSON之間的映射關(guān)系。

OTLP/gRPC

普通請求：在客戶端和服務(wù)端建立連接后，客戶端可以持續(xù)不斷的發(fā)送請求到服務(wù)端，服務(wù)端會一一回應(yīng)。 并發(fā)請求：客戶端可以在服務(wù)端未回應(yīng)前發(fā)送下一個請求，以此提高并發(fā)量。

Collector

Collector簡介

OpenTelemetry提供了開源的Collector來進行客戶端數(shù)據(jù)的上報采集，處理和輸出。otel collector是一個支持了多種協(xié)議，多種數(shù)據(jù)源的“萬能”采集器?？梢哉f是你能想到的很多數(shù)據(jù)源他都能夠直接支持。

otel collector使用golang實現(xiàn)，到文章目前編寫的時候已經(jīng)發(fā)布了1.0.0的rc版本。Collector區(qū)分為了兩個項目opentelemetry-collector，opentelemetry-collector-contrib。opentelemetry-collector是核心項目，實現(xiàn)了collector的基本機制以及一些基礎(chǔ)的組件，而opentelemetry-collector-contrib則會有大量的組件，而這些組件由于不同原因不便被直接集成到核心的collector中，因此單獨構(gòu)建了一個項目來集成這些組件。我們后續(xù)的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的上報數(shù)據(jù)，進行batch處理，然后輸出到控制臺日志和jaeger中。我們將各項數(shù)據(jù)源和插件配置完成后，在流水線中配置使用的數(shù)據(jù)源和插件。

Receiver

Receiver是指的接收器，即collector接收的數(shù)據(jù)源的形式。Receiver可以支持多個數(shù)據(jù)源，也能支持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的樣例，里面展示了多種不同的接收數(shù)據(jù)源的配置。

Processor

Processor是在Receiver和Exportor之間執(zhí)行的類似于處理數(shù)據(jù)的插件。Processor可以配置多個并且根據(jù)在配置中pipeline的順序，依次執(zhí)行。

以下是一些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&lt;documentId&gt;.*)\/update$
      from_attributes: ["db.svc", "operation"]
      separator: "::"

Exportor

Exportor是指的導(dǎo)出器，即collector輸出的數(shù)據(jù)源的形式。Exportor可以支持多個數(shù)據(jù)源，也能支持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的數(shù)據(jù)，他負責(zé)處理的是一些類似健康檢查服務(wù)發(fā)現(xiàn)，壓縮算法等等的非otel數(shù)據(jù)的擴展能力。

一些Extension樣例：

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

Service

上述的這些配置都是配置的具體數(shù)據(jù)源或者是插件本身的應(yīng)用配置，但是實際上的生效與否，使用順序都是在Service中配置。主要包含如下幾項：

extensions
pipelines
telemetry

Extensions是以數(shù)組的形式配置的，不區(qū)分先后順序：

service:
  extensions: [health_check, pprof, zpages]

pipelines配置區(qū)分trace，metrics和logs，每一項都可以配置單獨的receivers，processors和exportors，均是以數(shù)組的形式配置，其中processors的數(shù)組配置需要按照想要的執(zhí)行順序來配置，而其他的則無關(guān)順序。

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的環(huán)境，根據(jù)自己的需求修改代碼并且編譯。這種方式能夠完美自定義，但是會比較麻煩，特別是對于非golang的開發(fā)者，還需要搭建一套golang的環(huán)境實在是非常麻煩。

OpenTelemetry提供了一種ocb（OpenTelemetry Collector Builder）的方式來方便大家自定義Collector。感興趣的朋友可以參照此文檔使用。

總結(jié)

collector是整個調(diào)用鏈重要的一環(huán)，所有的客戶端的數(shù)據(jù)都需要一個統(tǒng)一的采集器來進行接收數(shù)據(jù)并進行一定的清洗工作和轉(zhuǎn)發(fā)工作。目前的OpenTelemetry Collector做了非常多的工作來保持兼容性和性能。期待OpenTelemetry Collector的1.0.0版本能夠早日正式發(fā)布。

以上就是詳解Opentelemetry Collector采集器的詳細內(nèi)容，更多關(guān)于Opentelemetry Collector采集器的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: