介绍一下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 内部主要包含五大类组件：

组件	作用
Receiver	接收数据
Processor	处理数据
Exporter	输出数据
Connector	Pipeline之间转发数据
Extension	提供辅助能力

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了。

我们用到了以下的组件：

组件类型	组件名称	组件用途
receiver	hostmetrics	获取所在主机的metrics
processor	batch	批处理，用于节省资源
processor	resourcedetection	读取环境信息
exporter	prometheus	展现Prometheus兼容的metrics端口
exporter	debug	打印信息，用于调试
extension	health_check	用于提供 /health 接口
extension	pprof	用于Collector性能分析
extension	zpages	提供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强大丰富的功能也值得这些时间的投入。