作者：来自 Elastic Nima Rezainia
Elastic 已完全采用 OpenTelemetry 作为其数据摄取策略的核心，积极与开源社区保持一致，并为其成为面向广大用户的最佳数据采集平台做出贡献。这一转变为用户带来了更高的灵活性、效率和对遥测数据的控制力。
引言
Elastic 已完全采用 OpenTelemetry 作为其数据摄取策略的核心，积极与开源社区保持一致，并为其成为面向广大用户的最佳数据采集平台做出贡献。这一转变为用户带来了更高的灵活性、效率以及对遥测数据的控制力。
为什么选择 OpenTelemetry？
OpenTelemetry 提供了一套强大的功能，使其成为专注于开源用户的理想选择。Elastic 正在围绕 OpenTelemetry 重新构建其数据摄取工具，以为用户提供与厂商无关的灵活性、通过 OTel 高效的数据模型实现的性能优化，以及对数据管道的更强灵活性与控制能力。这一转变将开源遥测的优势带给 Elastic 用户。
Elastic 的工程师在 OpenTelemetry 项目的多个领域都是活跃的贡献者。Elastic 积极参与开源，持续为 [](opentelemetry.devstats.cncf.io/d/5/compani… 项目做出重要贡献。
OpenTelemetry 作为 Elastic 数据摄取的核心
Elastic 正在将其数据摄取策略全面转向基于 OpenTelemetry 组件的架构。Elastic 当前支持以下基于 OTel 的摄取架构，支持来自 OTel 官方或 Elastic 自身发行版（EDOT）的 OTel SDK 和 Collector。
[
这标志着一次根本性的转变，确保遥测管道更加标准化和可扩展。所有现有的 Elastic 摄取组件都将基于 OTel。
| Beats | Beats 架构将基于 OTel。 |
| Elastic Agent | Agent 架构将基于 OTel，以支持基于 beats 的输入和 OTel 接收器。 |
| Integrations | 集成目录还将包含基于 OTel 的模块，以简化配置。 |
| Fleet central management | Fleet 将支持对 Elastic OTel collectors 的监控。 |
我们来讨论 Elastic 数据摄取平台的各个组件将如何基于 OpenTelemetry collector 构建，同时仍为用户提供相同的功能。
](opentelemetry.devstats.cncf.io/d/5/compani… 项目做出重要贡献。
OpenTelemetry 作为 Elastic 数据摄取的核心
Elastic 正在将其数据摄取策略全面转向基于 OpenTelemetry 组件的架构。Elastic 当前支持以下基于 OTel 的摄取架构，支持来自 OTel 官方或 Elastic 自身发行版（EDOT）的 OTel SDK 和 Collector。
[](opentelemetry.devstats.cncf.io/d/5/compani… 项目做出重要贡献。
OpenTelemetry 作为 Elastic 数据摄取的核心
Elastic 正在将其数据摄取策略全面转向基于 OpenTelemetry 组件的架构。Elastic 当前支持以下基于 OTel 的摄取架构，支持来自 OTel 官方或 Elastic 自身发行版（EDOT）的 OTel SDK 和 Collector。
Elastic 传统的数据采集器将重新设计为 OpenTelemetry Collectors，符合 OTel 的可扩展性模型。当前的 Beats 架构本质上由管道中的几个阶段组成，如下图所示。它包括输入、用于丰富数据的处理器、事件排队，以及用于批量处理和写入数据到特定输出的输出阶段。
Beatreceiver 概念
为了确保平稳过渡且不造成重大中断，正在实现 “beatsreceiver” 概念。这些 beatreceiver（如 filebeatreceiver 或 metricbeatreceiver）作为专用的 Beats 输入，集成到 OpenTelemetry Collector 中，作为原生接收器。它们支持所有现有的输入和处理器，保证最终架构能够接受用户当前的配置，并提供与现有 Beats 相同的功能，且不会引入任何破坏性变更。
基于 OTel 的 Beats 架构将把输入阶段嵌入为 OTel 接收器（例如，filebeatreceiver 代表 filebeat 的功能）。该接收器仅作为 Elastic 发行版中 OTel 的一部分提供，以支持我们当前的用户群，不会作为上游功能提供。
管道的所有其余组件都将基于 OTel。新的 Beats 将接受相同的 filebeat 配置（作为示例），并将其转换为基于 OTel 的配置，以避免任何部署中断。需要注意的是，在此架构中，Beats 仍将只支持 ECS 格式的数据。为了保持 Beats 功能与现有一致，Elasticsearch 导出器（作为示例）将仅输出 ECS 格式的数据。
下图展示了 beatreceiver 概念，说明了如何将基本的 filebeat 配置自动转换为基于 OpenTelemetry 的配置。该新配置保留了原始的输入和处理器，但利用了原生 OpenTelemetry 的管道和导出器，实现了与 filebeat 相同的整体功能。现有的 filebeat 配置将被自动转换，消除了手动调整或引入破坏性变更的需求。
Elastic Agent
Elastic Agent 是一个用于数据采集、安全和可观测性的统一代理。它也可以以仅 OpenTelemetry 模式部署，支持原生 OTel 工作流程。Elastic Agent 是一个管理多个 Beats 子进程的监督程序，旨在提供更全面的数据采集工具。它能够将来自 Fleet 的 Agent 策略转换为各子进程可接受的配置。
在上述 Beats 接收器概念的基础上，Elastic Agent 目前可以作为 OTel collector 部署（详见博客），也将被修改为基于这些接收器的更简化的 OTel 架构。如图所示，该架构将简化 Elastic Agent 内的组件，去除重复功能，如排队和输出。在支持现有功能的同时，这些改动将减少代理的资源占用，并减少代理出口连接到管道元素（如 Elasticsearch 集群、Logstash 或 Kafka 代理）的连接数。
通过转向基于 OTel 的架构，Elastic Agent 现在能够作为真正的混合型 Elastic Agent 运行，不仅提供 Beats 功能，还允许用户创建原生 OTel 管道，并利用开源项目提供的大量功能。
Elastic 对 OpenTelemetry 的承诺将通过增加贡献不断加深，OpenTelemetry 接收器将逐步取代 Beats 接收器的功能。这一演进最终会减少 Elastic Agent 架构中对独立 Beats 接收器的需求。未来的架构将使 Elastic Agent 能够以 OTLP 格式传输数据，赋予用户选择任何兼容 OTLP 后端的灵活性，从而坚持厂商中立的原则。
Fleet 和 Integrations：大规模管理 OpenTelemetry
Elastic 的集中管理系统将支持基于 OpenTelemetry 的配置，使大规模部署更易管理。管理成千上万的遥测代理是一个重大挑战。Elastic 的 Fleet 和 Integrations 通过提供这些基于 OpenTelemetry 的 Elastic 代理的强大生命周期管理，简化了这一过程。
主要能力包括：
-
可扩展性：管理分布式环境中的 10 万+ 代理。
-
自动升级：分阶段推出和自动升级，确保最小停机时间。
-
监控和诊断：实时状态更新、故障检测和诊断下载，提高系统可靠性。
-
基于策略的配置管理：实现对代理配置的集中控制，提升部署一致性。
-
预构建集成：Elastic 提供 470+ 个预构建集成，允许用户无缝接入各种数据源。这些集成也将包含基于 OTel 的包，极大提升大规模部署的配置效率。
目标是 Fleet 还将以厂商无关的方式提供对原生 OTel 收集器的监控能力。
总结
Elastic 采用 OpenTelemetry 标志着开源可观测性发展的重要里程碑。通过标准化使用 OpenTelemetry，Elastic 确保其数据采集策略保持开放、可扩展且具备未来适应性。
对开源用户来说，这一转变意味着：
-
可观测性工具间更好的互操作性。
-
选择遥测后端时更高的灵活性。
-
对社区驱动的可观测性标准更强的支持。
-
现有 Beats 和 Elastic Agent 用户可无缝采用 OpenTelemetry，无需重新架构管道。
-
OpenTelemetry 用户可以无额外复杂度地集成 Elastic 的可观测性堆栈。
请继续关注 Elastic 继续扩展基于 OpenTelemetry 的数据采集能力的最新动态！同时，这里有一些参考资料：
原文：Pivoting Elastic's Data Ingestion to OpenTelemetry — Elastic Observability Labs
