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 没有可用于假指标项目的 Docker 镜像；因此，我们需要构建它 截至撰写本文时的 OTEL Collector 最新版本 参数化以下配置文件 一切都发生在这里 正如我上面提到的，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 接收者列表。接收器读取数据；它可以是基于推式的，也可以是基于拉式的。 我们使用 预定义的接收器 prometheus 定义拉动作业 作业配置 出口商名单。与接收者不同，导出者写入数据。 最简单的导出器是将数据写入标准输出 管道组装接收器和输出器 定义与指标相关的管道 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 添加 导出器 prometheus 公开符合 Prometheus 标准的端点 以曝光代替印刷 就是这样。 OTEL Collector 非常灵活。 请注意，收集器是多输入、多输出的。为了打印数据并通过端点公开它们，我们将它们添加到管道中：   exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #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 使用 风味 contrib 为了增加乐趣，配置文件位于另一个路径上 此时，我们可以添加处理器本身：   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 调用指标转换处理器 按顺序应用的变换列表 将所有指标与定义的正则表达式匹配 按顺序应用的操作列表 添加标签 通过删除正则表达式组前缀来重命名指标 有趣的东西：语法是 $${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" ] 该指标名为  ，但其值仍为 1。 log_record_count_total 日志操作 处理器允许数据操作；操作员是处理日志的专门处理器。如果您熟悉 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 日志为JSON格式；我们可以使用提供的 JSON 解析器 要设置的元数据属性 要读取的字段 解析模式 映射表 接受一个范围，  。该运算符对 HTTP 状态有一个特殊的解释值  （及类似值）。 例如 501-599 5xx 删除重复数据 日志 此时，我们可以将日志发送到任意日志聚合组件。我们将留在 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 更进一步： 打开遥测收集器 开放遥测操作员 最初于 2023 年 11 月 12 日 于 发表 A Java Geek

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

深入研究 OpenTelemetry Collector

About Author

註釋

標籤

这篇文章刊登在

Related Stories

比特币 UTXO 模型，为独特的生态系统提供动力

加密货币增长：创建有效的用户角色

Claude Sonnet 3.5 系统提示泄漏：法医分析

Telegram：加密岛通往大陆的桥梁

比特币 UTXO 模型，为独特的生态系统提供动力

加密货币增长：创建有效的用户角色

Claude Sonnet 3.5 系统提示泄漏：法医分析

Telegram：加密岛通往大陆的桥梁

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps