前言

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

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

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

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

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

OTLP

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

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

OTLP/HTTP

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

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

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

OTLP/gRPC

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

Collector

Collector簡(jiǎn)介

OpenTelemetry提供了開(kāi)源的Collector來(lái)進(jìn)行客戶端數(shù)據(jù)的上報(bào)采集，處理和輸出。otel collector是一個(gè)支持了多種協(xié)議，多種數(shù)據(jù)源的“萬(wàn)能”采集器。可以說(shuō)是你能想到的很多數(shù)據(jù)源他都能夠直接支持。

otel collector使用golang實(shí)現(xiàn)，到文章目前編寫(xiě)的時(shí)候已經(jīng)發(fā)布了1.0.0的rc版本。Collector區(qū)分為了兩個(gè)項(xiàng)目opentelemetry-collector，opentelemetry-collector-contrib。opentelemetry-collector是核心項(xiàng)目，實(shí)現(xiàn)了collector的基本機(jī)制以及一些基礎(chǔ)的組件，而opentelemetry-collector-contrib則會(huì)有大量的組件，而這些組件由于不同原因不便被直接集成到核心的collector中，因此單獨(dú)構(gòu)建了一個(gè)項(xiàng)目來(lái)集成這些組件。我們后續(xù)的collector功能介紹和驗(yàn)證都會(huì)基于opentelemetry-collector-contrib來(lái)進(jìn)行。

Collector使用

otel collector的組成是很清晰的，分為：

• Receiver
• Processor
• Exporter
• Extension
• Service

整個(gè)配置文件的樣例如下：

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]

這個(gè)配置是我本地測(cè)試時(shí)使用的一個(gè)配置，這個(gè)配置很簡(jiǎn)單，接收otlp http/grpc的上報(bào)數(shù)據(jù)，進(jìn)行batch處理，然后輸出到控制臺(tái)日志和jaeger中。我們將各項(xiàng)數(shù)據(jù)源和插件配置完成后，在流水線中配置使用的數(shù)據(jù)源和插件。

Receiver

Receiver是指的接收器，即collector接收的數(shù)據(jù)源的形式。Receiver可以支持多個(gè)數(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:

上述是一個(gè)receiver的樣例，里面展示了多種不同的接收數(shù)據(jù)源的配置。

Processor

Processor是在Receiver和Exportor之間執(zhí)行的類似于處理數(shù)據(jù)的插件。Processor可以配置多個(gè)并且根據(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<documentId>.*)\/update$
      from_attributes: ["db.svc", "operation"]
      separator: "::"

Exportor

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

一些Extension樣例：

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

Service

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

• extensions
• pipelines
• telemetry

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

service:
  extensions: [health_check, pprof, zpages]

pipelines配置區(qū)分trace，metrics和logs，每一項(xiàng)都可以配置單獨(dú)的receivers，processors和exportors，均是以數(shù)組的形式配置，其中processors的數(shù)組配置需要按照想要的執(zhí)行順序來(lái)配置，而其他的則無(wú)關(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自身的日志級(jí)別和metrics的輸出地址：

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

個(gè)性化的Collector

如果你想要自定義個(gè)性化的Collector包含你想要的Receiver，Exportor等，一種終極的方案就是下載源代碼，然后配置golang的環(huán)境，根據(jù)自己的需求修改代碼并且編譯。這種方式能夠完美自定義，但是會(huì)比較麻煩，特別是對(duì)于非golang的開(kāi)發(fā)者，還需要搭建一套golang的環(huán)境實(shí)在是非常麻煩。

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

總結(jié)

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

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

最新評(píng)論