paint-brush
深入研究 OpenTelemetry Collectorby@nfrankel
1,306
1,306

深入研究 OpenTelemetry Collector

Nicolas Fränkel18m2023/11/18
Read on Terminal Reader

虽然 OTEL Collector 不是 OTEL 架构的强制性部分,但它是满足您所有数据处理需求的有用瑞士刀。
featured image - 深入研究 OpenTelemetry Collector
Nicolas Fränkel HackerNoon profile picture
0-item
1-item


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/fooprometheus/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上找到。


更进一步:


最初于 2023 年 11 月 12 日发表A Java Geek