介绍一下OpenTelemetry Collector

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，主动或者被动抓取各种数据，比如metrics，traces, 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

例如：

• otlp
• batch
• memory_limiter
• logging

特点：

• 体积小
• 稳定
• 企业级生产环境

2.2 Collector Contrib

这其实才是最常见的使用最广的发行版，也是CNCF维护的，包含数百个组件。项目地址是：https://github.com/open-telemetry/opentelemetry-collector-contrib/

例如：

Receiver：

• prometheus
• kafka
• zipkin
• jaeger
• hostmetrics
• kubeletstats

Exporter：

• loki
• tempo
• elasticsearch
• clickhouse
• splunk
• datadog

Processor：

• transform
• attributes
• filter
• tailsampling

实际生产环境中：

大多数部署的是这个 Contrib 版本

2.3 AWS Distro for OpenTelemetry（ADOT）

这是最著名的厂商发行版，在AWS上部署生产系统的用户几乎人人使用。

Amazon Web Services 推出的：AWS Distro for OpenTelemetry (ADOT)

特点包括：

• 完全开源
• 基于 OpenTelemetry Collector Contrib
• AWS 官方支持

主要增强包含：

Exporter 支持直接输出到：

• Amazon CloudWatch
• AWS X-Ray
• Amazon Managed Service for Prometheus

Kubernetes集成：

• Operator
• Helm Chart
• EKS自动部署

适合：

EKS ↓ ADOT Collector ↓ CloudWatch X-Ray AMP

此外还有对Lambda的原生支持。

ADOT是企业使用 AWS Observability 的标准方案。

2.4 Azure Monitor OpenTelemetry Distro

这是由 Microsoft 提供的发行版。

主要目标：

OpenTelemetry ↓ Azure Monitor

自动资源发现

自动识别：

• Azure VM
• AKS
• App Service
• Container Apps

资源标签自动补全：

• subscription
• resourceGroup
• region

2.5 Google Cloud Operations Collector

这是由 Google 提供的发行版。

主要目标：

OTel ↓ Google Cloud Operations

适合：

• GKE
• Compute Engine
• Cloud Run

2.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

形成完整的 LGTM+Profile 体系。

2.10 Elastic Distribution

这是由 Elastic 提供的发行版。

目标：

OTel ↓ Elastic Stack

3. 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 内部主要包含五大类组件：

OpenTelemetry Collector最基本的Pipeline形式为：

Receiver → Processor → Exporter

这个结构足够简单，但是会遇到一些复杂的问题。比如我们想利用Exporter输出的数据在处理一下，一个例子就是把输出的traces处理一下能生成很多有价值的RED metrics，那我们就不得不级联另一个OpenTelemetry Collector。对于一个负载很轻的小系统，这个级联并非必要。所以就引入了一个新的组件形式，叫做Connector，可以把内部的pipeline串起来，后面在介绍Connector的时候，我会说明。

1) 下面我举例说明一个最简单的trace Pipeline：

service: pipelines: traces: receivers: - otlp processors: - batch exporters: - jaeger

逻辑上是：

Traces Pipeline OTLP Receiver ↓ Batch Processor ↓ Jaeger Exporter

注意，每种监控信号（Signal）通常有独立 Pipeline：

• Metrics Pipeline
• Logs Pipeline
• Traces Pipeline
• Profiles Pipeline

其中 Profile（持续性能分析）是较新的能力。

2) 下面是一个相对完整的Pipeline例子，包括metrics，traces和logs：

service: 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 ↓ Loki

4.2 Receiver

Receiver 是 Pipeline 的入口。

Collector 中的 Receiver 负责：

• 监听端口
• 接收数据
• 协议解析
• 转换内部格式

例如：

• OTLP
• Prometheus
• Jaeger
• Zipkin
• Kafka
• HostMetrics
• KubeletStats

流程：

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/gRPC
• OTLP/HTTP

端口：

• 4317
• 4318

Prometheus Receiver

用于抓取 Metrics。

最简配置：

receivers: prometheus: config: scrape_configs: - job_name: node

HostMetrics Receiver

用于采集主机指标。

receivers: hostmetrics: collection_interval: 30s

采集：

• CPU
• Memory
• Disk
• Network

KubeletStats Receiver

采集 Kubernetes 节点数据。

最简配置：

receivers: kubeletstats:

采集metrics：

• Node
• Pod
• Container

4.3 Processor

Processor 是 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

下面介绍几个最常用的Processor：

Batch Processor

几乎所有生产环境都启用。

最简配置：

processors: batch:

作用：

• 批量发送
• 减少网络调用
• 提高吞吐量

Memory Limiter

防止 Collector OOM。

最简配置：

processors: memory_limiter: limit_mib: 2048

作用：

• 内存保护

Attributes Processor

增加标签。

最简配置：

processors: attributes: actions: - key: env value: prod action: insert

结果：

env=prod

加入所有遥测数据(telemetry data)。

Filter Processor

过滤数据。

最简配置：

processors: filter:

例如：

• 丢弃 DEBUG 日志
• 丢弃测试环境 Trace

Tail Sampling Processor

链路追踪(traces)最重要的 Processor。

processors: tail_sampling:

实现：

• 错误请求保留
• 正常请求抽样

例如：

• 100% ERROR
• 5% SUCCESS

大幅降低存储成本。

4.4 Exporter

Exporter 是 Pipeline 的终点。

例如：

• Prometheus
• Tempo
• Jaeger
• Kafka
• Loki
• OTLP
• ClickHouse
• Elastic

典型流程：

Receiver ↓ Processor ↓ Exporter

要查看Collector Contrib发行版的各种Exporter，请点击：https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter

下面介绍几个最常用的Exporter：

OTLP Exporter

最简配置：

exporters: otlp: endpoint: backend:4317

发送数据到下一个OTLP消费者。可能是某后端服务或者工具，或者另一个 Collector。

Prometheus Exporter

最简配置：

exporters: prometheus:

暴露：/metrics供 Prometheus 抓取。

Loki Exporter

发送日志。

常用于：

• Grafana Loki

Elasticsearch Exporter
发送日志和指标。
常用于：

• Elasticsearch

Kafka Exporter
发送到：
Apache Kafka
用于：

• 消息总线
• 数据湖
• 流式分析

4.5 Connector

这是近几年 Collector 架构最重要的变化之一。

Connector 出现以前，同一个OpenTelemetry Collector的Pipeline之间不能直接通信。只能交付级联的下一个OpenTelemetry Collector的Pipeline。

若希望：

Trace ↓ 生成 Metrics ↓ Metrics Pipeline

使用同一个OpenTelemetry Collector就基本做不到。

Connector 的本质是：Connector 同时具有：

• Pipeline A 的 Exporter
• Pipeline B 的 Receiver

双重身份，从而在一个OpenTelemetry Collector内接通两个Pipeline：

Pipeline A ↓ Connector ↓ Pipeline B

SpanMetrics Connector

这是目前使用最多的 Connector。

作用：

Trace ↓ RED Metrics ↓ Metric

生成：

• Request Rate
• Error Rate
• Duration

即经典 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/connector

4.6 Extension

Extension 不属于 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

下面介绍几个最常用的Extension：

Health 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.yaml

5.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.0

2) 如果采用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.0

5.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) 安装当前最高版本的GoLang

2) 下载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 ocb

3) 创建一个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.0

4) 编译生成自己定制的OpenTelemetry Collector。

./ocb --config builder-config.yaml

5) 如果还要生成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 --mount=type=cache,target=/root/.cache/go-build GO111MODULE=on go install go.opentelemetry.io/collector/cmd/builder@v0.153.0 RUN --mount=type=cache,target=/root/.cache/go-build builder --config builder-config.yaml FROM gcr.io/distroless/base:latest ARG USER_UID=10001 USER ${USER_UID} COPY ./collector-config.yaml /otelcol/collector-config.yaml COPY --from=certs /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt COPY --chmod=755 --from=build-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 \ --platform=linux/amd64,linux/arm64 . # Test the newly built image docker run -it --rm -p 4317:4317 -p 4318:4318 \ --name otelcol mycollecrot:0.01

6. 运行一个最简单的OpenTelemetry Collector的实例

请先按照章节5.1的描述，下载并展开一个OpenTelemetry Collector的二进制执行程序文件(otelcol-contrib)。

我们希望这个OpenTelemetry Collector能监控当前主机的metrics(包括CPU, memory, disk, network, process...)，然后展现一个供Prometheus使用的“/metrics” endpoint。这样Prometheus或者兼容的后端就可以读取这些metrics了。

我们用到了以下的组件：

以下是配置文件的示例(假定名称是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强大丰富的功能也值得这些时间的投入。