OpenTelemetry系列（三）｜神秘的采集器——OpentelemetryCollector

前言上一章我们主要介绍了OpenTelemetry客户端的一些数据生成方式，但是客户端的数据最终还是要发送到服务端进行统一采集整合，从而你可以看到完整的调用链、指标和其他信息。因此，本章主要介绍服务端的采集能力。客户端数据上报客户端会按照一定的规则生成调用链、指标、日志等信息，然后推送到远程服务器。一般来说，OpenTelemetry的server-client请求数据传输的协议标准是Http和Grpc协议，这两种数据协议的实现应该包含在各个语言的sdk和server实现中。按照常理，调用链等数据量巨大，所以在客户端会有一些类似Batch的操作选项。该选项会将多个Span信息整合在一起，一起发送，减少网络侧的损耗。.我们将这种客户端上报的数据统称为export，同时将实现这些上报的组件统称为exporter。导出器将包含不同的数据协议和格式，默认格式是OTLP。OTLPOTLP是指OpenTelemetryProtocol，即OpenTelemetry数据协议。OTLP规范规定了遥测数据在客户端和服务采集端之间的编码、传输和传递。OTLP从实现上分为OTLP/gRPC和OTLP/HTTP。OTLP/HTTPOTLP/HTTP在数据传输时支持两种模式：binary和jsonbinary使用proto3编码标准，请求头中必须标明Content-Type：application/x-protobufJSON格式使用定义的JSONMapping进行处理proto3标准中Protobuf与JSON的映射关系。OTLP/gRPC普通请求：客户端与服务端建立连接后，客户端可以不断向服务端发送请求，服务端会一一响应。并发请求：客户端可以在服务器响应之前发送下一个请求以增加并发量。CollectorCollector简介OpenTelemetry提供了一个开源的Collector来报告、收集、处理和输出客户端数据。otel收集器是一个支持多种协议和数据源的“通用”收集器。可以说他可以直接支持很多你能想到的数据源。otel收集器是用golang实现的，写文章的时候已经发布了rc1.0.0版本。Collector分为两个项目opentelemetry-collector和opentelemetry-collector-contrib。opentelemetry-collector是核心项目，实现了collector的基本机制和一些基础组件，而opentelemetry-collector-contrib会有大量的组件，这些组件因为各种原因不方便直接集成到核心collector中，所以单独构建了一个项目来集成这些组件。我们后续的collector功能介绍和验证会基于opentelemetry-collector-contrib。使用otelcollector的Collector组成非常清晰，分为：ReceiverProcessorExporterExtensionService整个配置文件的样例如下：receivers:otlp:protocols:grpc:http:exporters:jaeger:endpoint:localhost:14250tls:insecure:truelogging:loglevel:debugprocessors:batch:extensions:health_check:pprof:zpages:service:extensions:[pprof,zpages,health_check]pipelines:traces:receivers:[otlp]exporters:[jaeger,logging]处理器：[batch]这个配置是我本地测试用的A配置，这个配置很简单，接收otlphttp/grpc的上报数据，进行批处理，然后输出到控制台log和jaeger。在我们配置好各种数据源和插件之后，我们来配置流水线中使用的数据源和插件。ReceiverReceiver指的是接收者，即采集器接收到的数据源的形式。Receiver可以支持多种数据源，也可以支持pull和push模式。接收器：#数据源：日志fluentforward:endpoint:0.0.0.0:8006#数据源：指标hostmetrics:scrapers:cpu:disk:filesystem:load:memory:network:process:processes:swap:#数据源：tracesjaeger:protocols:grpc:thrift_binary:thrift_compact:thrift_http:#数据源：traceskafka:protocol_version:2.0.0#Datasources:traces,metricsopencensus:#数据源：traces,metrics,logsotlp:protocols:grpc:http:#Datasources:metricsprometheus:config:scrape_configs:-job_name:"otel-collector"scrape_interval:5sstatic_configs:-targets:["localhost:8888"]#Datasources:traceszipkin:以上是一个示例接收器，显示了各种配置用于接收数据源。ProcessorProcessor是一个类似于Receiver和Exportor之间执行的处理数据的插件。可以根据配置中管道的顺序配置多个处理器并依次执行。下面是一些Processor的配置示例：processors:#Datasources:tracesattributes:actions:-key:environmentvalue:productionaction:insert-key:db.statementaction:delete-key:emailaction:hash#Datasources:traces,metrics,logsbatch:#数据源：metricsfilter:metrics:include:match_type:regexpmetric_names:-prefix/.*-prefix_.*#数据源：traces,metrics,logsmemory_limiter:check_interval:5slimit_mib:4000spike_limit_mib:500#数据来源：tracesresource:attributes:-key:cloud.zonevalue:"zone-1"action:upsert-key:k8s.cluster.namefrom_attribute:k8s-clusteraction:insert-key:redundant-attributeaction:delete#数据来源：tracesprobabilistic_sampler:hash_seed:22sampling_percentage:15#数据来源：tracesspan:name:to_attributes:rules:-^\/api\/v1\/document\/(?P.*)\/update$from_attributes:["db.svc","operation"]分隔符："::"ExportorExportor指导出器，即采集器输出数据源的形式。Exportor可以支持多种数据源，也可以支持pull和push模式。下面是一些Exportor的例子：exporters:#Datasources:traces,metrics,logsfile:path:./filename.json#Datasources:tracesjaeger:endpoint:"jaeger-all-in-one:14250"tls:cert_file:cert.pemkey_file:cert-key.pem#数据源：traceskafka:protocol_version:2.0.0#数据源：traces,metrics,logslogging:loglevel:debug#数据源：traces,metricsopencensus:endpoint:"otelcol2:55678"#数据源：traces,metrics,logsotlp:endpoint:otelcol2:4317tls:cert_file:cert.pemkey_file:cert-key.pem#数据源：traces,metricsotlphttp:endpoint:https://example.com:4318/v1/traces#数据来源：metricsprometheus:endpoint:"prometheus:8889"namespace:"default"#数据来源：metricsprometheusremotewrite:endpoint:"http://some.url:9411/api/prom/push"#对于官方Prometheus（例如通过Docker运行）#endpoint:'http://prometheus:9090/api/v1/write'#tls:#insecure:true#Datasources:traceszipkin:endpoint:"http://localhost:9411/api/v2/spans"ExtensionExtension它是收集器的扩展。需要注意的是，Extension不处理otel数据。负责处理健康检查服务发现、压缩算法等非otel数据的一些扩展能力，一些扩展的例子：extensions:health_check:pprof:zpages:memory_ballast:size_mib:512Service以上配置是具体的数据源配置或者插件本身的应用配置，但是否真正生效，使用顺序是在Service中配置的。主要包括以下几项：extensionspipelinestelemetryExtensions以数组形式配置，不分先后顺序：service:extensions:[health_check,pprof,zpages]pipelines配置区分trace、metrics和logs，每一项可以单独配置receiver，processors和exportors都是以数组的形式配置的，其中processors的数组配置需要按照想要的执行顺序进行配置，其他的无关紧要。service:pipelines:metrics:receivers:[opencensus,prometheus]exporters:[opencensus,prometheus]traces:receivers:[opencensus,jaeger]processors:[batch]exporters:[opencensus,zipkin]telemetry配置收集器本身的配置，主要是log和metrics，下面的配置是配置collector本身的日志级别和metrics的输出地址：service:telemetry:logs:level:debuginitial_fields:service:my-instancemetrics:level:detailedaddress:0.0。0.0:8888PersonalizedCollector如果你想定制一个个性化的Collector，包括你想要的Receiver，Exportor等，一个最终的解决方案是下载源码，然后配置golang环境，根据需要修改代码并编译.这种方式可以完美定制，但是会比较麻烦，尤其是非golang开发者，搭建golang环境非常麻烦。OpenTelemetry提供了一个ocb（OpenTelemetryCollectorBuilder）方法来方便自定义Collector。有兴趣的朋友可以参考这个文档来使用。综上所述，收集器是整个调用链的重要组成部分。所有的客户端数据都需要一个统一的采集器来接收数据并进行一定的清洗和转发任务。当前的OpenTelemetryCollector在保持兼容性和性能方面做了很多工作。期待OpenTelemetryCollector1.0.0版本尽快正式发布。