前言
上个篇章中我们主要介绍了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
的组成是很清晰的,分为:
整个配置文件的样例如下:
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]
这个配置是我本地测试时使用的一个配置,这个配置很简单,接收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: 512
Service
上述的这些配置都是配置的具体数据源或者是插件本身的应用配置,但是实际上的生效与否,使用顺序都是在Service
中配置。主要包含如下几项:
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版本能够早日正式发布。