OpenTelemetry 系列 （三）｜ 神秘的采集器 - Opentelemetry Collector
前言
上个篇章中我们主要介绍了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
整个配置文件的样例如下：
这个配置是我本地测试时使用的一个配置，这个配置很简单，接收otlp http/grpc的上报数据，进行batch处理，然后输出到控制台日志和jaeger中。我们将各项数据源和插件配置完成后，在流水线中配置使用的数据源和插件。
Receiver
Receiver是指的接收器，即collector接收的数据源的形式。Receiver可以支持多个数据源，也能支持pull和push两种模式。
上述是一个receiver的样例，里面展示了多种不同的接收数据源的配置。
Processor
Processor是在Receiver和Exportor之间执行的类似于处理数据的插件。Processor可以配置多个并且根据在配置中pipeline的顺序，依次执行。
以下是一些Processor的配置样例：
Exportor
Exportor是指的导出器，即collector输出的数据源的形式。Exportor可以支持多个数据源，也能支持pull和push两种模式。
以下是一些Exportor的样例：
Extension
Extension是collector的扩展，要注意Extension不处理 otel 的数据，他负责处理的是一些类似健康检查服务发现，压缩算法等等的非 otel 数据的扩展能力。
一些Extension样例：
Service
上述的这些配置都是配置的具体数据源或者是插件本身的应用配置，但是实际上的生效与否，使用顺序都是在Service中配置。主要包含如下几项：
extensions
pipelines
telemetry
Extensions是以数组的形式配置的，不区分先后顺序：
pipelines配置区分trace，metrics和logs，每一项都可以配置单独的receivers，processors和exportors，均是以数组的形式配置，其中processors的数组配置需要按照想要的执行顺序来配置，而其他的则无关顺序。
telemetry配置的是collector本身的配置，主要是log和metrics，下列配置就是配置了collector自身的日志级别和metrics的输出地址：
个性化的 Collector
如果你想要自定义个性化的Collector包含你想要的Receiver，Exportor等，一种终极的方案就是下载源代码，然后配置 golang 的环境，根据自己的需求修改代码并且编译。这种方式能够完美自定义，但是会比较麻烦，特别是对于非 golang 的开发者，还需要搭建一套 golang 的环境实在是非常麻烦。
OpenTelemetry提供了一种ocb（OpenTelemetry Collector Builder）的方式来方便大家自定义Collector。感兴趣的朋友可以参照此文档使用。
总结
collector是整个调用链重要的一环，所有的客户端的数据都需要一个统一的采集器来进行接收数据并进行一定的清洗工作和转发工作。目前的OpenTelemetry Collector做了非常多的工作来保持兼容性和性能。期待OpenTelemetry Collector的 1.0.0 版本能够早日正式发布。
版权声明: 本文为 InfoQ 作者【骑牛上青山】的原创文章。
原文链接:【http://xie.infoq.cn/article/37120a87ef93c16db658b4e79】。文章转载请联系作者。
还未添加个人签名 2021-05-18 加入
还未添加个人简介
评论