深入研究 OpenTelemetry Collector

OpenTelemetry Collector 位于 OpenTelemetry 架构的中心，但与 W3C Trace Context 无关。在我的跟踪演示中，我使用 Jaeger 而不是 Collector。然而，它无处不在，就像在每个与 OpenTelemetry 相关的帖子中一样。我想进一步探索它。

在这篇文章中，我探讨了收集器的不同方面：

• 数据类型：日志、指标和跟踪
• 推拉模型
• 操作：读取、转换和写入

第一步

很久以前，我们所知的可观察性并不存在；我们所拥有的只是监控。当时，监控是一群人看着显示仪表板的屏幕。仪表板本身包含指标并且仅包含系统指标：主要是 CPU、内存和磁盘使用情况。出于这个原因，我们将从指标开始。

Prometheus是主要的监控解决方案之一。它适用于基于拉取的模型：Prometheus 抓取应用程序的兼容端点并将其存储在内部。

我们将使用 OTEL Collector 来抓取 Prometheus 兼容的端点并在控制台中打印结果。 Grafana Labs 提供了一个可以生成随机指标的项目。为了简单起见，我将使用 Docker Compose；设置如下所示：

 version: "3" services: fake-metrics: build: ./fake-metrics-generator #1 collector: image: otel/opentelemetry-collector:0.87.0 #2 environment: #3 - METRICS_HOST=fake-metrics - METRICS_PORT=5000 volumes: - ./config/collector/config.yml:/etc/otelcol/config.yaml:ro #4

1. 没有可用于假指标项目的 Docker 镜像；因此，我们需要构建它
2. 截至撰写本文时的 OTEL Collector 最新版本
3. 参数化以下配置文件
4. 一切都发生在这里

正如我上面提到的，OTEL Collector 可以做很多事情。因此，配置就是一切。

 receivers: #1 prometheus: #2 config: scrape_configs: #3 - job_name: fake-metrics #4 scrape_interval: 3s static_configs: - targets: [ "${env:METRICS_HOST}:${env:METRICS_PORT}" ] exporters: #5 logging: #6 loglevel: debug service: pipelines: #7 metrics: #8 receivers: [ "prometheus" ] #9 exporters: [ "logging" ] #9

1. 接收者列表。接收器读取数据；它可以是基于推式的，也可以是基于拉式的。
2. 我们使用prometheus预定义的接收器
3. 定义拉动作业
4. 作业配置
5. 出口商名单。与接收者不同，导出者写入数据。
6. 最简单的导出器是将数据写入标准输出
7. 管道组装接收器和输出器
8. 定义与指标相关的管道
9. pipeline从之前定义的prometheus接收器获取数据并发送给logging导出器，即打印出来

以下是结果示例：

 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 83.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #1 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__embrace_world_class_systems: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(extranet) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(challenge) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(support) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__strategize_strategic_initiatives: Str(internet_solution) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__whiteboard_innovative_partnerships: Str(matrices) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 53.090000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #2 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__expedite_distributed_partnerships: Str(approach) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(policy) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(algorithm) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2023-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1970-01-01 00:00:00 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2023-11-11 07:28:54.14 +0000 UTC 2023-11-11 08:28:54 otel-collector-collector-1 | Value: 16.440000 2023-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #3 2023-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(graphical_user_interface) 2023-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(extranet)

超越印刷

上面是一个很好的第一步，但不仅仅是打印到控制台。我们将公开由常规 Prometheus 实例抓取的指标；我们可以添加Grafana 仪表板来可视化它们。虽然这看起来毫无意义，但请忍受它，因为它只是一块垫脚石。

为了实现上述目的，我们只需更改 OTEL Collector 配置：

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3

1. 添加prometheus导出器
2. 公开符合 Prometheus 标准的端点
3. 以曝光代替印刷

就是这样。 OTEL Collector 非常灵活。

请注意，收集器是多输入、多输出的。为了打印数据并通过端点公开它们，我们将它们添加到管道中：

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3

1. 公开数据
2. 打印数据
3. 管道将打印数据并公开它们

配置 Prometheus 导出器后，我们可以在 Grafana 中可视化指标。

请注意，接收者和导出者指定其类型，并且每个类型都必须是唯一的。为了满足最后一个要求，我们可以附加一个限定符来区分它们，即prometheus/foo和prometheus/bar.

中间数据处理

一个有效的问题是为什么 OTEL Collector 设置在源和 Prometheus 之间，因为它使整体设计更加脆弱。在此阶段，我们可以利用 OTEL Collector 的真正强大功能：数据处理。到目前为止，我们已经获取了原始指标，但源格式可能不适合我们想要的数据可视化方式。例如，在我们的设置中，指标来自我们的假生成器“业务”和底层 NodeJS 平台“技术”。它反映在指标的名称中。我们可以添加专用的源标签并删除不必要的前缀以更有效地过滤。

您可以在配置文件的processors部分中声明数据处理器。收集器按照声明的顺序执行它们。让我们来实现上面的转换。

实现我们目标的第一步是了解收集器有两种风格：“裸”风格和基于它的贡献风格。前者包含的处理器在数量和功能上都有限；因此，我们需要切换 contrib 版本。

 collector: image: otel/opentelemetry-collector-contrib:0.87.0 #1 environment: - METRICS_HOST=fake-metrics - METRICS_PORT=5000 - PROMETHEUS_PORT=8889 volumes: - ./config/collector/config.yml:/etc/otelcol-contrib/config.yaml:ro #2

1. 使用contrib风味
2. 为了增加乐趣，配置文件位于另一个路径上

此时，我们可以添加处理器本身：

 processors: metricstransform: #1 transforms: #2 - include: ^fake_(.*)$ #3 match_type: regexp #3 action: update operations: #4 - action: add_label #5 new_label: origin new_value: fake - include: ^fake_(.*)$ match_type: regexp action: update #6 new_name: $${1} #6-7 # Do the same with metrics generated by NodeJS

1. 调用指标转换处理器
2. 按顺序应用的变换列表
3. 将所有指标与定义的正则表达式匹配
4. 按顺序应用的操作列表
5. 添加标签
6. 通过删除正则表达式组前缀来重命名指标
7. 有趣的东西：语法是$${x}

最后，我们将定义的处理器添加到管道中：

 service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ]

结果如下：

连接接收方和出口方

连接器既是接收器又是输出器，连接两条管道。文档中的示例接收跨度数（跟踪）并导出具有指标的计数。我试图以 500 个错误实现相同的目标 - 剧透：它没有按预期工作。

我们首先添加一个日志接收器：

 receivers: filelog: include: [ "/var/logs/generated.log" ]

然后，我们添加一个连接器：

 connectors: count: requests.errors: description: Number of 500 errors condition: [ "status == 500 " ]

最后，我们连接日志接收器和指标导出器：

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "count" ] metrics: receivers: [ "prometheus", "count" ]

该指标名为log_record_count_total ，但其值仍为 1。

日志操作

处理器允许数据操作；操作员是处理日志的专门处理器。如果您熟悉 Elasticsearch Logstash Kibana 堆栈，它们相当于 Logstash。

截至目前，日志时间戳是摄取时间戳。我们将其更改为其创建的时间戳。

 receivers: filelog: include: [ "/var/logs/generated.log" ] operators: - type: json_parser #1 timestamp: #2 parse_from: attributes.datetime #3 layout: "%d/%b/%Y:%H:%M:%S %z" #4 severity: #2 parse_from: attributes.status #3 mapping: #5 error: 5xx #6 warn: 4xx info: 3xx debug: 2xx - id: remove_body #7 type: remove field: body - id: remove_datetime #7 type: remove field: attributes.datetime - id: remove_status #7 type: remove field: attributes.status

1. 日志为JSON格式；我们可以使用提供的 JSON 解析器
2. 要设置的元数据属性
3. 要读取的字段
4. 解析模式
5. 映射表
6. 接受一个范围，例如501-599 。该运算符对 HTTP 状态有一个特殊的解释值5xx （及类似值）。
7. 删除重复数据

日志

此时，我们可以将日志发送到任意日志聚合组件。我们将留在 Grafana Labs 领域并使用 Loki。

 exporters: loki: endpoint: "http://loki:3100/loki/api/v1/push"

我们还可以使用收集器本身的日志：

 service: telemetry: logs:

最后，让我们添加另一个管道：

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ]

Grafana 还可以可视化日志。选择 Loki 作为数据源。

结论

在这篇文章中，我们深入研究了 OpenTelemetry 收集器。虽然它不是 OTEL 架构的强制性部分，但它是满足您所有数据处理需求的有用瑞士刀。如果您没有陷入特定堆栈或不想这样做，这将是一个巨大的帮助。

这篇文章的完整源代码可以在GitHub上找到。

更进一步：

• 打开遥测收集器
• 开放遥测操作员