共计 5501 个字符,预计需要花费 14 分钟才能阅读完成。
前言
上个篇章中咱们次要介绍了 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: 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
- 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 版本可能早日正式公布。