OpenTelemetry系列 （三）｜ 神秘的采集器 - Opentelemetry Collector

最新推荐文章于 2025-10-08 14:33:05 发布
原创 最新推荐文章于 2025-10-08 14:33:05 发布 · 4.3k 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#服务器 #java #运维

前言

上个篇章中我们主要介绍了OpenTelemetry的客户端的一些数据生成方式，但是客户端的数据最终还是要发送到服务端来进行统一的采集整合，这样才能看到完整的调用链，metrics等信息。因此在这个篇章中会主要介绍服务端的采集能力。

客户端数据上报

客户端会根据一定的规则生成调用链，metrics，logs等信息，然后就会将其推送到服务器远端。一般来说OpenTelemetry的服务端客户端传递数据的请求协议标准是Http和Grpc协议，在各语言的sdk以及服务端实现中都应该包含这两个数据协议的的实现。

按照常理来说调用链等数据的数据量极大，因此在客户端就会有一些类似于Batch的操作选项，此选项会将多个Span信息整合到一起一并发送，以减小网络端的损耗。

客户端的这种数据上报我们会统称为export，同时，实现这些上报的组件我们统一称作exporters。exporters会包含不同种的数据协议和格式，默认的格式为OTLP。

OTLP

OTLP是指OpenTelemetry Protocol，即OpenTelemetry数据协议。OTLP规范规定了客户端和服务采集端之间的遥测数据的编码,传输和投送。

OTLP在实现上分为OTLP/gRPC和OTLP/HTTP。

OTLP/HTTP

OTLP/HTTP在数据传输的时候支持两种模式：二进制和json

二进制使用proto3编码标准，且必须在请求头中标注Content-Type: application/x-protobuf

JSON格式使用proto3标准定义的JSON Mapping来处理Protobuf和JSON之间的映射关系。

OTLP/gRPC

普通请求：在客户端和服务端建立连接后，客户端可以持续不断的发送请求到服务端，服务端会一一回应。 并发请求：客户端可以在服务端未回应前发送下一个请求，以此提高并发量。

Collector

Collector简介

OpenTelemetry提供了开源的Collector来进行客户端数据的上报采集，处理和输出。otel collector是一个支持了多种协议，多种数据源的“万能”采集器。可以说是你能想到的很多数据源他都能够直接支持。

otel collector使用golang实现，到文章目前编写的时候已经发布了1.0.0的rc版本。Collector区分为了两个项目opentelem

最低0.47元/天 解锁文章
【云原生】springboot 整合 OpenTelemetry
congge
01-14 1万+
springboot 整合 OpenTelemetry
OpenTelemetryCollector-数据集散中心
qq_35427785的博客
02-07 4168
声明：本文撰写日期为<2021年2月>，截至目前，该OpenTelemetry尚未发布第一个Release版本，仍然处于快速迭代状态。 一、OpenTelemetryCollector 简介 OpenTelemetryCollector源码下载地址：open-telemetry-collector 在我的博客《OpenTelemetry简介-结束分布式追踪的江湖之乱》中简单介绍了OpenTelemetry的应用架构，在下图中，负责中间数据转换的部分，就是OpenTelemetryCo.
入门OpenTelemetry——部署OpenTelemetry
qq_33816243的博客
05-14 1919
OpenTelemetry Collector 按部署方式分为 Agent 和Gateway 模式。
Prometheus是如何从otel-collector收取数据的
u012534547的博客
03-13 795
收集 OpenTelemetry 采集的 Metrics。监控 Java 服务的 Metrics 了！Prometheus 需要配置。✅ Prometheus 通过。✅ 配置 Prometheus。让它定期拉取 Metrics。🚀 这样，你就可以用。
17、OpenTelemetry Collector 深度解析
最新发布
earth的博客
10-08 40
本文深入解析了OpenTelemetry Collector的核心组件与工作原理，包括接收器、处理器和导出器的配置与使用场景，详细介绍了各组件的功能与典型配置示例。文章还提供了最佳实践、完整配置案例、流程图以及常见问题解答，帮助用户高效构建可扩展、安全合规的遥测数据处理管道。
使用opentelemetry搭建全链路追踪系统
gdutlhh的专栏
04-08 1871
由于项目是分布式微服务架构系统，为了实现服务的可观察性，决定搭建一套可观测的系统。由于我们当前使用的是go，而opentelemetry标准也是目前比较推荐的，并且其支持多语言，于是就想到用otel来搞了。废话不多说，进入主题。
OpenTelemetry系列 - 第3篇 OpenTelemetry Collector
罗小爬的技术宝书
12-02 5078
是一个与供应商无关的代理，可以接收、处理和导出遥测数据。它支持接收多种格式的遥测数据(例如，OTLP、Jaeger、Prometheus，以及许多商业/专有工具)并将数据发送到一个或多个后端它还支持在导出遥测数据之前对其进行处理和过滤Receivers 接收器- 接收器可以是基于推或拉的，它是数据进入收集器的方式。接收器可以支持一个或多个数据源。Processors 处理器- 处理器在接收和导出之间的数据上运行。处理器是可选的，但有些是推荐的。Exporters 导出器。
opentelemetry-collector-contrib:OpenTelemetry收集器的Contrib存储库
04-06
•• ••• •• OpenTelemetry收集器贡献 这是OpenTelemetry Collector贡献的存储库，它不属于Collector的。 通常，这些贡献是特定于供应商的接收者/出口者和/或组件，仅对相对较少的用户有用。 请注意，此存储库及其发行版是核心存储库的超集。 贡献 参见CONTRIBUTING.md 。 分类器（ @ open-telemetry / collector-contrib-triagers ） 许安德（ Andrew Hsu ） 史蒂夫·弗兰德斯（ Steve Flanders ） 批准人（ @ open-telemetry / collector-contrib-approvers ）： 阿努拉格·阿格劳瓦尔（Anurag Agrawal ） 丹尼尔·贾格洛夫斯基（ Daniel Jaglowski ） 德米特里·阿诺申（ Dmi
入门OpenTelemetry——日志数据采集与导出
qq_33816243的博客
06-05 2084
Logging。
观测云接收 OpenTelemetry Collector 数据最佳实践
观测云的博客
08-13 1104
本文介绍观测云如何接收 OpenTelemetry Collector 数据进行统一查看和分析，帮助用户实现灵活的可观测性数据管理体系。
入门OpenTelemetry——收集器配置详解
qq_33816243的博客
05-22 1610
OpenTelemetry 的 Collector 组件是实现观测数据（Trace、Metrics、Logs）收集、处理和导出的一站式服务。它的配置主要分为以下。
OpenTelemetry Collector简介
u_geek的博客
12-20 3774
OpenTelemetry Collector 旨在提供一个与设备无关的采集器，用于接受，处理和输出观测数据。此外，使用OpenTelemetry Collector也避免了我们运行、维护多个agents/collector。
opentelemetry-collector：OpenTelemetry收集器
02-10
•• ••••• OpenTelemetry收集器 OpenTelemetry Collector在如何接收，处理和导出遥测数据方面提供了与供应商无关的实现。 另外，它消除了运行，操作和维护多个代理/收集器的需要，以便支持发送到多个开源或商业后端的开源遥测数据格式（例如Jaeger，Prometheus等）。 目标： 可用：合理的默认配置，支持流行的协议，可以运行并立即使用。 性能：在不同的负载和配置下具有很高的稳定性和性能。 可观察的：可观察服务的示例。 可扩展：可定制，无需接触核心代码。 统一：单一代码库，可部署为代理或收集器，并支持跟踪，指标和日志。 贡献 参见 。 分类器（ ）： ，Lightstep 批准人（ ）： （ ） 红帽的 维护者（ ）： （ ） 了解有关角色的更多。 感谢所有已经做出贡献的人们！
15、OpenTelemetry Collector 全面解析：部署、组件与监控
plum99的博客
07-14 244
本文全面解析了OpenTelemetry Collector的部署模式、核心组件及其配置方法，并介绍了如何通过监控指标优化其运行。内容涵盖Agent模式和Gateway模式的对比、接收器、处理器、导出器和扩展的功能与配置示例，以及在Docker、Kubernetes和不同操作系统上的部署操作步骤，帮助读者更好地管理和处理遥测数据，提升应用程序的性能与稳定性。
OpenTelemetry Collector 架构详解：从数据采集到导出的全流程
gitblog_00278的博客
09-09 1365
你是否正面临以下挑战：微服务架构下数据采集杂乱无章？多语言应用监控需要维护多种代理？数据处理逻辑重复开发？OpenTelemetry Collector（简称 OTel Collector）作为开源可观测性领域的核心组件，通过**统一的数据管道**解决了这些问题。本文将深入剖析其内部架构，带你掌握从数据采集到导出的全流程实现机制。 读完本文你将获得： - 理解 Collector 核心组件的协作...
【亲测免费】 OpenTelemetry Collector 安装和配置指南
gitblog_09536的博客
09-13 1973
OpenTelemetry Collector 安装和配置指南 1. 项目基础介绍和主要的编程语言 项目基础介绍 OpenTelemetry Collector 是一个开源的、可扩展的代理，用于接收、处理和导出遥测数据（如 traces、metrics 和 logs）。它旨在作为一个中间层，帮助用户收集和导出数据到不同的后端服务，如 Prometheus、Jaeger、Elasticsearch ...
神奇的数据收集器 - OpenTelemetry Collector Go
BetiFunction的博客
09-17 406
OpenTelemetry Collector Go是OpenTelemetry的Go语言实现版，它提供了一种简单而灵活的方式来收集、转换和导出观测数据。OpenTelemetry Collector Go是OpenTelemetry的Go语言实现版，它提供了一种简单而灵活的方式来收集、转轻松地收集和处理观测数据。OpenTelemetry Collector Go是OpenTelemetry的Go语言实现版，它提供了一种简单而灵活的方式轻松地收集和处理观测数据。以下是一个基轻松地收集和处理观测数据。
探索OpenTelemetry Collector：开源监控的未来
gitblog_00464的博客
09-03 387
OpenTelemetry Collector是一个开源项目，旨在提供一个与供应商无关的实现，用于接收、处理和导出遥测数据。它消除了运行、操作和维护多个代理/收集器的需要，支持从流行的开源遥测数据格式（如Jaeger、Prometheus等）到多个开源或商业后端的转换。 ## 项目技术分析 OpenTelemetry Collector基于Go语言开发，利用OpenTelemetry协议（OT...
OpenTelemetry系列 （一）｜ OpenTelemetry的前世今生
m0_57042151的博客
12-21 592
这是我的Opentelemetry系列文章的第一篇，主要是介绍一些分布式追踪的往事和Opentelemetry诞生的历史。
opentelemetry-collector-contrib采集到指标中的时间戳是被采集端提供还是由opentelemetry-collector-contrib设置，还是存入时序数据库的时间
04-26
<think>好的，我现在需要回答用户关于OpenTelemetry Collector Contrib采集指标时间戳来源的问题。首先，我需要回忆一下OpenTelemetry（OTel）的基本架构和数据流。用户提到的是collector-contrib，这是OTel Collector的一个扩展版本，包含了许多第三方组件和接收器/导出器。 根据引用内容，OTel主要负责生成、收集和导出遥测数据，如指标、日志和跟踪，但并不存储这些数据。用户的问题集中在指标的时间戳来源，特别是采集端如何设置，以及存储到时序数据库的情况。 首先，时间戳的来源可能有几个方面。首先是数据生成的时间点，也就是在应用程序中使用OTel SDK埋点的时候，SDK会自动记录当前时间作为时间戳。例如，当使用Counter或Gauge等Metric Instruments时，SDK会在记录指标值时打上时间戳，这应该是采集数据的最原始时间来源。这点可能在引用中的Meter & Metric Instruments部分有所涉及。 其次是Collector处理过程中的时间戳处理。当Collector接收到指标数据时，是否有可能修改或重新生成时间戳？根据OTel的设计，Collector应该尽量保持数据的原始性，除非进行显式的处理。例如，如果使用某些处理器（如Batch Processor），可能会对时间戳进行调整，或者在数据延迟的情况下添加接收时间戳。但默认情况下，Collector应该保留原始的时间戳。 另外，如果数据源本身没有提供时间戳（比如某些老旧系统或被动拉取的指标），Collector可能会在采集时自动生成时间戳，记录接收到数据的时间。例如，当使用Prometheus Receiver从目标拉取指标时，Prometheus Exporter通常会为每个指标附加拉取时的时间戳，而Collector可能保留这个时间戳，或者在配置中允许覆盖。 存储到时序数据库（如Prometheus、InfluxDB）时，这些数据库如何处理时间戳？通常，数据库会直接存储指标中的时间戳，而不会修改它。但有些情况下，如果时间戳缺失，数据库可能会使用数据写入的时间作为替代。需要确认OTel Collector在导出数据时是否确保时间戳的正确传递。 可能还需要考虑不同接收器（Receivers）和导出器（Exporters）的行为差异。例如，OTLP Receiver可能会保留原始时间戳，而其他接收器可能根据协议规范处理时间戳。导出器在发送数据到后端时是否有可能修改时间戳，或者添加额外的时间字段。 最后，用户可能需要了解如何验证时间戳的来源，例如通过查看Collector的日志、配置选项或使用调试工具检查导出的指标数据。此外，配置文件中可能有一些参数可以调整时间戳的行为，比如是否使用接收时间覆盖原始时间戳。 总结一下，时间戳的主要来源是数据生成时的SDK记录，其次是Collector接收或处理时的补充，而存储到数据库时通常保留原有时间戳。需要将这些点整理成结构清晰的回答，并引用提供的参考资料中的相关内容。</think>### OpenTelemetry Collector Contrib 指标时间戳来源解析 #### 1. **时间戳的原始来源（采集端）** - **SDK 自动生成** 当应用程序通过 OpenTelemetry SDK 生成指标时，SDK 会在指标数据生成时自动添加当前系统时间戳。例如： - 使用 $Counter$ 或 $Gauge$ 等 Metric Instruments 时，时间戳由 SDK 在记录指标值时自动生成[^3]。 - 异步计数器（如 $Asynchronous\ Counter$）在回调函数触发时记录时间戳。 - **手动指定时间戳** 开发者可通过 SDK API 显式设置时间戳，适用于需要记录历史数据或自定义时间逻辑的场景。 #### 2. **Collector 处理过程中的时间戳行为** - **默认保留原始时间戳** OpenTelemetry Collector 在接收数据时，默认会保留 SDK 或数据源提供的原始时间戳，遵循观测性数据收集的统一规范[^1]。 - **特殊场景处理** - **无时间戳的数据源**：若数据源未提供时间戳（如部分日志文件或被动拉取协议），Collector 会在接收数据时添加当前时间戳。例如： ```python # 伪代码示例：Collector 接收数据时补充时间戳 if metric.timestamp is None: metric.timestamp = time.now() ``` - **时间戳修正**：通过 Processor（如 `BatchProcessor`）可对时间戳进行批量调整，例如处理延迟数据时对齐时间窗口。 #### 3. **存储至时序数据库的时间戳** - **直接透传原始时间戳** 时序数据库（如 Prometheus、InfluxDB）通常会直接存储指标中的时间戳。例如： - Prometheus 通过 Exporters 接收数据时，会保留原始时间戳用于查询和聚合[^2]。 - **写入时间覆盖（可选）** 部分数据库支持配置“写入时间”作为替代时间戳，但需显式启用（如 InfluxDB 的 `use_server_time` 参数）。 #### 4. **关键配置与验证** - **Collector 配置示例** 在 `receivers` 或 `exporters` 中指定时间戳行为： ```yaml receivers: prometheus: skip_metric_timestamp: false # 是否保留原始时间戳 exporters: prometheusremotewrite: add_timestamp: true # 导出时是否添加 Collector 接收时间戳 ``` - **调试方法** 使用日志或 OpenTelemetry 调试工具（如 `loggingexporter`）检查指标时间戳是否与预期一致。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值