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
整个配置文件的样例如下：
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]processors: [batch]
复制代码这个配置是我本地测试时使用的一个配置，这个配置很简单，接收otlp http/grpc的上报数据，进行batch处理，然后输出到控制台日志和jaeger中。我们将各项数据源和插件配置完成后，在流水线中配置使用的数据源和插件。
Receiver
Receiver是指的接收器，即collector接收的数据源的形式。Receiver可以支持多个数据源，也能支持pull和push两种模式。
receivers:# Data sources: logsfluentforward:endpoint: 0.0.0.0:8006# Data sources: metricshostmetrics:scrapers:cpu:disk:filesystem:load:memory:network:process:processes:swap:# Data sources: tracesjaeger:protocols:grpc:thrift_binary:thrift_compact:thrift_http:# Data sources: traceskafka:protocol_version: 2.0.0# Data sources: traces, metricsopencensus:# Data sources: traces, metrics, logsotlp:protocols:grpc:http:# Data sources: metricsprometheus:config:scrape_configs:- job_name: "otel-collector"scrape_interval: 5sstatic_configs:- targets: ["localhost:8888"]# Data sources: traceszipkin:
复制代码上述是一个receiver的样例，里面展示了多种不同的接收数据源的配置。
Processor
Processor是在Receiver和Exportor之间执行的类似于处理数据的插件。Processor可以配置多个并且根据在配置中pipeline的顺序，依次执行。
以下是一些Processor的配置样例：
processors:# Data sources: tracesattributes:actions:- key: environmentvalue: productionaction: insert- key: db.statementaction: delete- key: emailaction: hash# Data sources: traces, metrics, logsbatch:# Data sources: metricsfilter:metrics:include:match_type: regexpmetric_names:- prefix/.*- prefix_.*# Data sources: traces, metrics, logsmemory_limiter:check_interval: 5slimit_mib: 4000spike_limit_mib: 500# Data sources: tracesresource:attributes:- key: cloud.zonevalue: "zone-1"action: upsert- key: k8s.cluster.namefrom_attribute: k8s-clusteraction: insert- key: redundant-attributeaction: delete# Data sources: tracesprobabilistic_sampler:hash_seed: 22sampling_percentage: 15# Data sources: tracesspan: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, logsfile:path: ./filename.json# Data sources: tracesjaeger:endpoint: "jaeger-all-in-one:14250"tls:cert_file: cert.pemkey_file: cert-key.pem# Data sources: traceskafka:protocol_version: 2.0.0# Data sources: traces, metrics, logslogging:loglevel: debug# Data sources: traces, metricsopencensus:endpoint: "otelcol2:55678"# Data sources: traces, metrics, logsotlp:endpoint: otelcol2:4317tls:cert_file: cert.pemkey_file: cert-key.pem# Data sources: traces, metricsotlphttp:endpoint: https://example.com:4318/v1/traces# Data sources: metricsprometheus:endpoint: "prometheus:8889"namespace: "default"# Data sources: metricsprometheusremotewrite: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: traceszipkin:endpoint: "http://localhost:9411/api/v2/spans"
复制代码Extension
Extension是collector的扩展，要注意Extension不处理otel的数据，他负责处理的是一些类似健康检查服务发现，压缩算法等等的非otel数据的扩展能力。
一些Extension样例：
extensions:health_check:pprof:zpages:memory_ballast:size_mib: 512
复制代码Service
上述的这些配置都是配置的具体数据源或者是插件本身的应用配置，但是实际上的生效与否，使用顺序都是在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: debuginitial_fields:service: my-instancemetrics:level: detailedaddress: 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版本能够早日正式发布。
OpenTelemetry系列 （三）｜ 神秘的采集器 - Opentelemetry Collector相关推荐
- Jvm 系列(三):GC 算法 垃圾收集器
这篇文件将给大家介绍GC都有哪几种算法,以及JVM都有那些垃圾回收器,它们的工作原理. 概述 垃圾收集 Garbage Collection 通常被称为"GC",它诞生于1960年 ...
- jvm系列(三):GC算法 垃圾收集器
概述 垃圾收集 Garbage Collection 通常被称为"GC",它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了. jvm 中,程序计数 ...
- 免费采集器：全方位深度分析！
在如今的信息时代,数据已经成为了企业运营和决策中不可或缺的一部分.然而,要想获取大量的数据,需要付出巨大的成本和精力.免费采集器应运而生,它能够帮助企业快速.高效地获取所需的数据.本文将从以下八个方面 ...
- Mocha NTA基于单采集器实现的多种流协议分析
业内主流的Flow协议技术 网络业界基于流(Flow)的分析技术主要有NetFlow.sFlow.cFlow和NetStreem四种.NetFlow是Cisco公司的独有技术,它既是一 ...
- 夜莺初探三·Categraf采集器
前言 github仓库文档中对Categraf有很详细的介绍,简单重复一下就是:支持多种数据格式的remote_write:All-in-one的设计理念,指标采集只需要一个agent完成,也计划支持 ...
- 《视频直播技术详解》系列之七：现代播放器原理
七牛云于 6 月底发布了一个针对视频直播的实时流网络 LiveNet 和完整的直播云解决方案,很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣. 结合七牛实时流网络 LiveNet 和直播云解 ...
- 《视频直播技术详解》系列之二：采集
七牛云于 6 月底发布了一个针对视频直播的实时流网络 LiveNet 和完整的直播云解决方案,很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣. 结合七牛实时流网络 LiveNet 和直播云解 ...
- 「视频直播技术详解」系列之六：现代播放器原理
关于直播的技术文章不少,成体系的不多.我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面.深入地了解视频直播技术,更好地技术选型. 本系列文章大纲如下: ...
- 电压越低采集的ad值反而变大_Cu100电流采集器诚信经营-泰华仪表
Cu100电流采集器诚信经营Cu100电流采集器诚信经营 随着电气系统自动化程度的提高,对电气系统的检测要求也越来越高.需要采集各种信号,如电流.电压.功率.频率.功率因数等.这些信号通过电量变送器转 ...
最新文章
- 熬了一个通宵，终于把 7 千万个 Key 删完了
- 浮点类型和布尔类型（Java）
- Matlab概率统计编程指南
- 一个按键控制数码管的开和关_三菱PLC数码管显示及按键控制实验
- jsonp的原理·jsonp是不是ajax中实现跨域访问的技术
- C++ TR1、TR2与boost的关系
- 大话存储pdf 百度网盘_学用系列｜亲身体验百度网盘内测在线文档，有遗憾也有期待...
- 如何在应用内设计一份调查？
- seq()函数--R语言
- 一个有趣的Java编译问题
- 逆clarke变换_克拉克(CLARKE)及帕克(PARK)变换.pdf
- Computer：路由器连接交换机怎么建立局域网
- matlab利用经纬度计算距离_经纬度换算距离(matlab根据经纬度算距离公式)
- RPLIDAR最强参数详解
- （4.3）进程管理之线程
- Word Embedding Papers | 经典再读之Word2Vec
- HTML基础之label标签
- mysql的主从复制和半同步复制的配置
- 推荐一些免费的网盘给你
- 通信系统CMMB调研报告