1. 前言1.1 OpenTelemetry Collector是什么?OpenTelemetry Collector毋庸置疑是OpenTelemetry用户使用得最多的工具。我搞了这个介绍OpenTelemetry的技术专栏按理说早就应该重点介绍一下OpenTelemetry Collector。主要是因为OpenTelemetry Collector的内容实在太多结果一拖再拖。今天写的这篇文章主要是给大家一个相对完整的不过时的信息概要不可能面面俱到OpenTelemetry Collector的各个方面。一些相对复杂的有关题目留待以后的文章里进行介绍。OpenTelemetry Collector简称 OTel Collector则是 OpenTelemetry 体系中的核心数据处理引擎。可以把它理解为一个专门负责接收、处理、转换、过滤和转发遥测数据的通用中间件。其位置通常如下Application │ ▼ OpenTelemetry SDK │ ▼ OpenTelemetry Collector │ B├── Prometheus A├── Jaeger C├── Tempo K├── Loki E├── Elasticsearch N├── ClickHouse D├── Data Lake └── ... ...Collector 的出现使得应用程序无需关心最终数据发送到哪里。应用只负责发送到 Collector。Collector 负责数据路由数据过滤数据增强数据转换数据导出1.2 为什么需要 OpenTelemetry Collector有人问为什么需要OpenTelemetry Collector中转一下难道我们不能直接把数据直接发送给OpenTelemetry Backends (处理监控数据的后端系统)?这里有很多原因首先还有很多后端系统(处理监控数据的服务或工具)不支持OpenTelemetry原生的传输协议OTLP还有很多前端系统(发送监控数据的系统或者工具)也不支持OTLP但是它们有交换数据的需要。所以即便仅仅为了中转OpenTelemetry Collector也是非常有益的。OpenTelemetry Collector可以把前后端的耦合性剪短使前后端系统的升级和替换更加轻松。OpenTelemetry Collector作为一个中间平台其功能实在太多了什么转换、安全认证、批处理、路由等等。Collector有各种Receiver组件本身就可以作为极其强大的Agent主动或者被动抓取各种数据比如metricstraces, logs, profiles等等可以跑在各种平台上。2. Collector 的种类得到最广泛使用的是 CNCF 社区维护的 OpenTelemetry Collector 发行版包括Core 和 Contrib两种。另外许多云厂商、APM 厂商和可观测性平台都提供了基于 OpenTelemetry Collector 定制的发行版Distribution。这些发行版通常不会从零开发一个新的 Collector而是在官方 Collector 的基础上增加专有 Receiver、Processor、Exporter等组件提供预配置增加运维管理能力增加安全认证能力与自身云平台深度集成下面就分别介绍一下2.1 Collector Core by CNCF这是CNCF官方最小发行版。项目地址是https://github.com/open-telemetry/opentelemetry-collector/只包含最基础 Receivers最基础 Processors最基础 Exporters例如otlpbatchmemory_limiterlogging特点体积小稳定企业级生产环境2.2 Collector Contrib这其实才是最常见的使用最广的发行版也是CNCF维护的包含数百个组件。项目地址是https://github.com/open-telemetry/opentelemetry-collector-contrib/例如ReceiverprometheuskafkazipkinjaegerhostmetricskubeletstatsExporterlokitempoelasticsearchclickhousesplunkdatadogProcessortransformattributesfiltertailsampling实际生产环境中大多数部署的是这个 Contrib 版本2.3 AWS Distro for OpenTelemetryADOT这是最著名的厂商发行版在AWS上部署生产系统的用户几乎人人使用。Amazon Web Services 推出的AWS Distro for OpenTelemetry (ADOT)特点包括完全开源基于 OpenTelemetry Collector ContribAWS 官方支持主要增强包含Exporter 支持直接输出到Amazon CloudWatchAWS X-RayAmazon Managed Service for PrometheusKubernetes集成OperatorHelm ChartEKS自动部署适合EKS ↓ ADOT Collector ↓ CloudWatch X-Ray AMP此外还有对Lambda的原生支持。ADOT是企业使用 AWS Observability 的标准方案。2.4 Azure Monitor OpenTelemetry Distro这是由 Microsoft 提供的发行版。主要目标OpenTelemetry ↓ Azure Monitor自动资源发现自动识别Azure VMAKSApp ServiceContainer Apps资源标签自动补全subscriptionresourceGroupregion2.5 Google Cloud Operations Collector这是由 Google 提供的发行版。主要目标OTel ↓ Google Cloud Operations适合GKECompute EngineCloud Run2.6 Splunk Distribution of OpenTelemetry Collector这是由 Splunk 提供的发行版。深度集成 Splunk Observability Cloud拥有大量现成监控插件2.7 Datadog OpenTelemetry Collector这是由 Datadog 提供的发行版。与DataDog紧密集成。2.8 New Relic OpenTelemetry Collector这是由 New Relic 提供的发行版。与New Relic紧密集成。New Relic奉行OpenTelemetry优先。2.9 Grafana Alloy这是近几年增长最快的 Collector 发行版之一。由 Grafana Labs 推出。主要目标Application ↓ Grafana Alloy ↓ Mimir Loki Tempo Pyroscope形成完整的 LGTMProfile 体系。2.10 Elastic Distribution这是由 Elastic 提供的发行版。目标OTel ↓ Elastic Stack3. OpenTelemetry Collector 的部署和运行模式官方推荐四种模式3.1 Agent 模式每台机器一个 Collector如果在Kubernetes就是DaemonSet。Node A ├─ Apps ↘ └─ Collector ━━━━━━➔┃ ┃ Node B ┃ Backend ├─ Apps ↘ ┃ └─ Collector ━━━━━━➔┃优点本地采集网络开销小缺点管理节点较多3.2 Gateway 模式集中部署 Collector。host1(apps) host2(apps) ... │ │ ▼ ▼ OpenTelemetry Collector │ ▼ Backend优点集中管理缺点性能瓶颈单点故障3.3 Sidecar 模式Pod ├─ App └─ Collector这一般是Kubernetes的专有概念。或者类似结构。3.4 复合模式可以综合以上各种模式。注意OpenTelemetry Collector的级联本身不会造成信息的损失其实还可以通过Processor增加一些信息当然很多的级联有一些性能的损失。所以设计OpenTelemetry Collector的通路是很自由的。4. OpenTelemetry Collector 的内部架构4.1 组件种类和Pipeline目前 OpenTelemetry Collector 内部主要包含五大类组件组件作用Receiver接收数据Processor处理数据Exporter输出数据ConnectorPipeline之间转发数据Extension提供辅助能力OpenTelemetry Collector最基本的Pipeline形式为Receiver → Processor → Exporter这个结构足够简单但是会遇到一些复杂的问题。比如我们想利用Exporter输出的数据在处理一下一个例子就是把输出的traces处理一下能生成很多有价值的RED metrics那我们就不得不级联另一个OpenTelemetry Collector。对于一个负载很轻的小系统这个级联并非必要。所以就引入了一个新的组件形式叫做Connector可以把内部的pipeline串起来后面在介绍Connector的时候我会说明。1) 下面我举例说明一个最简单的trace Pipelineservice: pipelines: traces: receivers: - otlp processors: - batch exporters: - jaeger逻辑上是Traces Pipeline OTLP Receiver ↓ Batch Processor ↓ Jaeger Exporter注意每种监控信号Signal通常有独立 PipelineMetrics PipelineLogs PipelineTraces PipelineProfiles Pipeline其中 Profile持续性能分析是较新的能力。2) 下面是一个相对完整的Pipeline例子包括metricstraces和logsservice: pipelines: traces: receivers: - otlp processors: - memory_limiter - batch exporters: - otlp metrics: receivers: - otlp - prometheus processors: - batch exporters: - prometheus logs: receivers: - otlp processors: - batch exporters: - loki对应数据流Traces: OTLP ↓ MemoryLimiter ↓ Batch ↓ OTLP Metrics: OTLP ↓ Batch ↓ Prometheus Logs: OTLP ↓ Batch ↓ Loki4.2 ReceiverReceiver 是 Pipeline 的入口。Collector 中的 Receiver 负责监听端口接收数据协议解析转换内部格式例如OTLPPrometheusJaegerZipkinKafkaHostMetricsKubeletStats流程OTLP/gRPC ↓ OTLP Receiver ↓ Collector Internal Data Model要查看Collector Contrib发行版的各种Receiver请点击https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver下面介绍几个最常用的Receiver:OTLP Receiver无疑这是最常用的 Receiver。最简配置receivers: otlp: protocols: grpc: http:接收OTLP/gRPCOTLP/HTTP端口43174318Prometheus Receiver用于抓取 Metrics。最简配置receivers: prometheus: config: scrape_configs: - job_name: nodeHostMetrics Receiver用于采集主机指标。receivers: hostmetrics: collection_interval: 30s采集CPUMemoryDiskNetworkKubeletStats Receiver采集 Kubernetes 节点数据。最简配置receivers: kubeletstats:采集metricsNodePodContainer4.3 ProcessorProcessor 是 Pipeline 中间处理层。作用过滤采样聚合属性修改转换限流批处理例如OTLP Receiver ↓ Attributes Processor ↓ Filter Processor ↓ Batch Processor ↓ OTLP Exporter举例说明Processor的配置processors: - memory_limiter - attributes - filter - batch注意执行顺序是memory_limiter ↓ attributes ↓ filter ↓ batch注意配置的顺序非常重要要查看Collector Contrib发行版的各种Processor请点击https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor下面介绍几个最常用的ProcessorBatch Processor几乎所有生产环境都启用。最简配置processors: batch:作用批量发送减少网络调用提高吞吐量Memory Limiter防止 Collector OOM。最简配置processors: memory_limiter: limit_mib: 2048作用内存保护Attributes Processor增加标签。最简配置processors: attributes: actions: - key: env value: prod action: insert结果envprod加入所有遥测数据(telemetry data)。Filter Processor过滤数据。最简配置processors: filter:例如丢弃 DEBUG 日志丢弃测试环境 TraceTail Sampling Processor链路追踪(traces)最重要的 Processor。processors: tail_sampling:实现错误请求保留正常请求抽样例如100% ERROR5% SUCCESS大幅降低存储成本。4.4 ExporterExporter 是 Pipeline 的终点。例如PrometheusTempoJaegerKafkaLokiOTLPClickHouseElastic典型流程Receiver ↓ Processor ↓ Exporter要查看Collector Contrib发行版的各种Exporter请点击https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter下面介绍几个最常用的ExporterOTLP Exporter最简配置exporters: otlp: endpoint: backend:4317发送数据到下一个OTLP消费者。可能是某后端服务或者工具或者另一个 Collector。Prometheus Exporter最简配置exporters: prometheus:暴露/metrics供 Prometheus 抓取。Loki Exporter发送日志。常用于Grafana LokiElasticsearch Exporter发送日志和指标。常用于ElasticsearchKafka Exporter发送到Apache Kafka用于消息总线数据湖流式分析4.5 Connector这是近几年 Collector 架构最重要的变化之一。Connector 出现以前同一个OpenTelemetry Collector的Pipeline之间不能直接通信。只能交付级联的下一个OpenTelemetry Collector的Pipeline。若希望Trace ↓ 生成 Metrics ↓ Metrics Pipeline使用同一个OpenTelemetry Collector就基本做不到。Connector 的本质是Connector 同时具有Pipeline A 的 ExporterPipeline B 的 Receiver双重身份从而在一个OpenTelemetry Collector内接通两个PipelinePipeline A ↓ Connector ↓ Pipeline BSpanMetrics Connector这是目前使用最多的 Connector。作用Trace ↓ RED Metrics ↓ Metric生成Request RateError RateDuration即经典 RED 指标。架构OTLP Trace ↓ SpanMetrics Connector ↓ Metrics Pipeline ↓ Prometheus配置示例... connectors: spanmetrics: ... service: pipelines: traces: receivers: [otlp] exporters: [spanmetrics] metrics: receivers: [spanmetrics] exporters: [prometheus]这里spanmetrics同时出现在Exporter和Receiver的位置。此外其它常用的Connector包括ServiceGraph Connector - 用于生成服务拓扑图Routing Connector - 用于动态路由Count Connector - 用于统计数据量要查看Collector Contrib发行版的各种Connector请点击https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector4.6 ExtensionExtension 不属于 Pipeline。Extension不处理遥测数据它用于配置OpenTelemetry Collector的运行环境。例如Health Check - 提供“/health”接口pprof - 提供Collector 性能分析zpages - 提供Collector内部运行状态oauth2client - 提供认证支持要查看Collector Contrib发行版的各种Extension请点击https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension下面介绍几个最常用的ExtensionHealth Check Extension最简配置extensions: health_check:用于提供/health 接口。pprof Extension最简配置extensions: pprof:用于Collector 性能分析。zpages Extension最简配置extensions: zpages:用于Collector 内部运行状态。oauth2client Extension最简配置extensions: oauth2client:用于认证支持。5. 部署和运行OpenTelemetry Collector的方法5.1 独立运行OpenTelemetry Collector执行程序(二进制文件)运行OpenTelemetry Collector非常简单仅需一个二进制执行程序和一个YAML配置文件而已。由于有多种发行版我这里仅以最广泛使用的OpenTelemetry Collector Contrib为例其它发行版类同。首先下载适合自己平台的OpenTelemetry Collector Contrib发行版。地址是https://github.com/open-telemetry/opentelemetry-collector-releases/releases一般是是下载最新的版本。比如最常见的是Linux AMD64的最新版本“otelcol-contrib_0.153.0_linux_amd64.tar.gz”。也可以使用命令wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.153.0/otelcol-contrib_0.153.0_linux_amd64.tar.gz然后展开这个包即可。如果下载的是.tar.gz文件可以用以下的命令tar vzxf /opt/stp/otelcol-contrib_0.153.0_linux_amd64.tar.gz展开得到的执行程序文件叫做“otelcol-contrib”。下一步就是写一个配置文件目的是配置Pipeline和extension关于Pipeline和extension详见上面的说明。下面是一个极其简单的示例配置文件(假如配置文件的名称是 config.yaml)使用OTLP receiver通过OTLP协议接收数据(metrics,traces,logs)。使用debug exporter把信息打印到控制台。中间使用的是batch processor可以提升效率。总共有metrics,traces,logs一共3个pipeline。receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 cors: allowed_origins: - http://* - https://* exporters: debug: verbosity: detailed processors: batch: service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [debug] metrics: receivers: [otlp] processors: [batch] exporters: [debug] logs: receivers: [otlp] processors: [batch] exporters: [debug]用如下命令可以启动OpenTelemetry Collector (假如配置文件的名称是 config.yaml):./otelcol-contrib --config ./config.yaml5.2 使用Docker安装/启动OpenTelemetry Collector还是需要自己写一个配置文件参见上一节的例子假如名称还是config.yaml。然后我们需要下载并运行一个Docker容器。1) 如果采用DockerHub的话请用以下命令docker pull otel/opentelemetry-collector:0.153.0 docker run -v $(pwd)/config.yaml:/etc/otelcol/config.yaml otel/opentelemetry-collector:0.153.02) 如果采用ghcr.io的话请用以下命令docker pull ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector:0.153.0 docker run -v $(pwd)/config.yaml:/etc/otelcol/config.yaml ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector:0.153.05.3 在Kubernetes Cluster内安装/启动OpenTelemetry Collector一个最简单的办法直接执行如下命令kubectl apply -f https://raw.githubusercontent.com/open-telemetry/opentelemetry-collector/v0.153.0/examples/k8s/otel-config.yaml可以修改对应配置文件的ConfigMap然乎重启OpenTelemetry Collector对用的Daemonset即可。很多企业级系统更倾向于使用Helm Chart来进行安装和部署这些用户可以参考OpenTelemetry Helm Charts。另外一个工具就更强大了它不仅仅是安装OpenTelemetry Collector还可以对各种编程语言的应用Pod自动注入对应语言的OpenTelemetry Agent。这些用户可以安装OpenTelemetry Operator。如果有必要后面会写文章专门介绍。5.4 (高级)定制自己的OpenTelemetry Collector这个题目是相对高级一点的话题初学者可以跳过。虽然实践中大部分用户直接采用了OpenTelemetry Collector Contrib或者云平台提供的OpenTelemetry Collector发行版(比如ADOT)。但是对于一些需要大规模部署OpenTelemetry Collector的用户或者需要严格管控系统资源消耗的用户OpenTelemetry Collector Contrib有几百个组件大多数都不会用到其运行态消耗的很多内存是不必要的。所以需要裁剪OpenTelemetry Collector Contrib成为自己系统专用的更小型的OpenTelemetry Collector。(当然还有一些定制的要求是要自己开发一些目前还没有的组件比如自定义的Receiver, Processor,Exporter等我会在其它文章讲解)。以下是通过裁剪来定制自己的OpenTelemetry Collector的详细步骤1) 安装当前最高版本的GoLang2) 下载OpenTelemetry Collector Builder (ocb)cd /opt/dev/otel/ocb/ curl --proto https --tlsv1.2 -fL -o ocb \ https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/cmd%2Fbuilder%2Fv0.153.0/ocb_0.153.0_linux_amd64 chmod x ocb3) 创建一个YAML文件标注需要哪些组件。可供定制的组件内容非常丰富读者可以参考 Registry | OpenTelemetry用户可以挑选自己需要的Receiver, Processor, Exporter等组件文档有示例如何假如这些定制组件。以下是示例(假设名称是 builder-config.yaml)dist: name: otelcol-dev description: Basic OTel Collector distribution for Developers output_path: ./otelcol-dev exporters: - gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.153.0 - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.153.0 processors: - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.153.0 receivers: - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.153.0 providers: - gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.48.0 - gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.48.0 - gomod: go.opentelemetry.io/collector/confmap/provider/httpprovider v1.48.0 - gomod: go.opentelemetry.io/collector/confmap/provider/httpsprovider v1.48.0 - gomod: go.opentelemetry.io/collector/confmap/provider/yamlprovider v1.48.04) 编译生成自己定制的OpenTelemetry Collector。./ocb --config builder-config.yaml5) 如果还要生成Docker Image的话创建一个Dockerfile文件FROM alpine:3.19 AS certs RUN apk --update add ca-certificates FROM golang:1.25.0 AS build-stage WORKDIR /build COPY ./builder-config.yaml builder-config.yaml RUN --mounttypecache,target/root/.cache/go-build GO111MODULEon go install go.opentelemetry.io/collector/cmd/builderv0.153.0 RUN --mounttypecache,target/root/.cache/go-build builder --config builder-config.yaml FROM gcr.io/distroless/base:latest ARG USER_UID10001 USER ${USER_UID} COPY ./collector-config.yaml /otelcol/collector-config.yaml COPY --fromcerts /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt COPY --chmod755 --frombuild-stage /build/otelcol-dev /otelcol ENTRYPOINT [/otelcol/otelcol-dev] CMD [--config, /otelcol/collector-config.yaml] EXPOSE 4317 4318 12001使用下述命令创建Docker Image# Enable Docker multi-arch builds docker run --rm --privileged tonistiigi/binfmt --install all docker buildx create --name mybuilder --use # Build the Docker image as Linux AMD and ARM # and load the result to docker images docker buildx build --load \ -t mycollecrot:0.01 \ --platformlinux/amd64,linux/arm64 . # Test the newly built image docker run -it --rm -p 4317:4317 -p 4318:4318 \ --name otelcol mycollecrot:0.016. 运行一个最简单的OpenTelemetry Collector的实例请先按照章节5.1的描述下载并展开一个OpenTelemetry Collector的二进制执行程序文件(otelcol-contrib)。我们希望这个OpenTelemetry Collector能监控当前主机的metrics(包括CPU, memory, disk, network, process...)然后展现一个供Prometheus使用的“/metrics” endpoint。这样Prometheus或者兼容的后端就可以读取这些metrics了。我们用到了以下的组件组件类型组件名称组件用途receiverhostmetrics获取所在主机的metricsprocessorbatch批处理用于节省资源processorresourcedetection读取环境信息exporterprometheus展现Prometheus兼容的metrics端口exporterdebug打印信息用于调试extensionhealth_check用于提供 /health 接口extensionpprof用于Collector性能分析extensionzpages提供Collector内部运行状态以下是配置文件的示例(假定名称是hostmetrics.yaml)receivers: hostmetrics: collection_interval: 30s scrapers: cpu: memory: load: network: processes: process: hostmetrics/disk: collection_interval: 1m scrapers: disk: filesystem: paging: exporters: prometheus: endpoint: 0.0.0.0:8889 debug: verbosity: detailed processors: batch: resourcedetection: detectors: [env, system] timeout: 2s override: true system: hostname_sources: [os] extensions: health_check: pprof: endpoint: :1888 zpages: endpoint: :55679 service: extensions: [pprof, zpages, health_check] pipelines: metrics: receivers: [hostmetrics, hostmetrics/disk] processors: [batch, resourcedetection] exporters: [debug, prometheus]注意我使用了两种频率来运行hostmetrics receiver。用30秒的周期来查询CPU, memory等metrics用1分钟的周期来查询disk相关的metrics。这是因为disk的变化没那么快。我这么做可以减少调用的次数减少一些CPU的消耗。你也可以都用30秒或者1分钟。下面我们运行如下的命令./otelcol-contrib --config ./hostmetrics.yaml这时候我们就能使用浏览器观察“http://127.0.0.1:8889/metrics”就可以看到大量的主机metrics。过1分钟后所有的metrics都可以展现。下面是我截取的一小段屏幕显示7. 总结OpenTelemetry Collector是OpenTelemetry用户用得最多的工具在I/T监控和运维领域也极受欢迎。我在这篇文章里给了读者一个OpenTelemetry Collector的全貌概要包括组件机理和配置示例等。熟练掌握OpenTelemetry Collector是每一个OpenTelemetry程序员或者系统管理员的基本要求。当然OpenTelemetry Collector强大丰富的功能也值得这些时间的投入。