前言
上个篇章中咱们次要介绍了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: debugprocessors: 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: 512Service
上述的这些配置都是配置的具体数据源或者是插件自身的利用配置，然而实际上的失效与否，应用程序都是在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。感兴趣的敌人能够参照此文档应用。
总结
collector是整个调用链重要的一环，所有的客户端的数据都须要一个对立的采集器来进行接收数据并进行肯定的荡涤工作和转发工作。目前的OpenTelemetry Collector做了十分多的工作来放弃兼容性和性能。期待OpenTelemetry Collector的1.0.0版本可能早日正式公布。