Elastic 数据采集全面转向 OpenTelemetry

引言

Elastic 已经将 OpenTelemetry 完全纳入数据采集策略的核心，和开源社区保持一致，并积极贡献代码，致力于把 OpenTelemetry 打造成面向广大用户的最佳数据采集平台。

这一转变为用户带来了更高的灵活性、效率与对遥测数据的可控性。

为什么选择 OpenTelemetry？

OpenTelemetry 提供了一套强大的能力，使其成为偏好开源的用户的明智之选。Elastic 正在围绕 OpenTelemetry 重新构建数据采集工具，以便：

1. 让用户在供应商之间自由切换（vendor-agnostic）。
2. 借助 OTel 高效的数据模型优化性能，轻松关联不同类型遥测数据。
3. 提升数据管道的灵活性与可控性。

Elastic 工程师活跃于 OpenTelemetry 社区的多个子项目，充分体现出对开源的承诺。Elastic 在过去一年里对 OpenTelemetry 的贡献情况可见一斑。

OpenTelemetry 成为 Elastic 数据采集的核心

Elastic 正在把所有采集机制统一到 OpenTelemetry 组件上。目前 Elastic 支持以下 OTel 架构，可兼容官方或 Elastic 发行版（EDOT，Elastic Distribution of OpenTelemetry）的 SDK 与 Collector。

EDOT components

这是一项根本性的变革，确保了更标准且可扩展的遥测管道。现有的所有 Elastic 采集组件都会逐步迁移到 OTel 体系。

下面我们分别说明各组件如何在不改变用户体验的前提下，基于 OpenTelemetry Collector 实现同等功能。

Beats

Elastic 传统的数据 Shipper 将被重新打造为 OpenTelemetry Collector，符合 OTel 的可扩展模型。当前 Beats 的流水线由 Input、Processor（数据增强）、队列、Output 几个阶段组成，如下图所示：

filebeat

beatreceiver 概念

为确保平滑迁移，我们引入了 “beatreceiver” 概念。

这些 Beats Receiver（例如 filebeatreceiver、metricbeatreceiver）作为 原生 Receiver 集成到 OpenTelemetry Collector 中，兼容现有的所有 Beats 输入与 Processor。也就是说，用户的当前配置可以直接复用，不会产生破坏性修改。

在 OTel 化后的 Beats 架构里，Input 阶段会封装成对应的 OTel Receiver（例如 filebeatreceiver 对应 filebeat 功能）。此 Receiver 仅在 Elastic 的 OTel 发行版中提供，以服务现有用户，官方上游并不会包含该组件。

filebeat

流水线中的其余阶段全部采用 OTel 组件。新的 Beats 可以读取原有 filebeat 配置文件，并自动转换为 OTel 配置，避免部署中断。需要注意：此架构仍仅支持 ECS（Elastic Common Schema）格式输出。举例来说，elasticsearch exporter 会继续输出 ECS 数据。

下图展示了 beatreceiver 的原理：基础 filebeat 配置被自动翻译为 OpenTelemetry 管道，同时保留原有的输入与处理逻辑，并通过 OTel 原生 exporter 达到与旧 filebeat 一致的效果。整个过程无需人工修改。

Filebeat OTel config

Elastic Agent

Elastic Agent 是一个统一的代理，涵盖数据采集、安全与可观测性，也可在 仅 OpenTelemetry 模式 下运行，支持 OTel 原生工作流。它作为守护进程，负责管理多个 Beats 子进程，并将来自 Fleet 的 Agent Policy 转译为各子进程可识别的配置。

Elastic Agent Architecture

基于前文的 Beats Receiver 概念，Elastic Agent（已支持作为 OTel Collector 部署，详见博文）将进一步精简为 纯 OTel 架构。如下图所示，新架构去除了多余的排队与输出逻辑，降低了资源占用，并减少了向下游（Elasticsearch、Logstash、Kafka 等）建立的连接数。

迁移到 OTel 后，Elastic Agent 变成真正意义上的 混合代理：既保持 Beats 能力，又允许用户构建 OTel 原生流水线，充分利用开源社区丰富的 Receiver、Processor 与 Exporter。

Elastic Agent OTel Architecture

随着 Elastic 对 OpenTelemetry 的持续投入，OTel Receiver 将逐步覆盖 Beats Receiver 的功能，最终无需专门的 Beats Receiver。届时，Elastic Agent 也可输出 OTLP 格式数据，让用户自由选择任何兼容 OTLP 的后端，进一步贯彻供应商中立原则。

Fleet & Integrations：大规模管理 OpenTelemetry

在大规模场景中，管理成千上万个遥测代理颇具挑战。Elastic 的 Fleet & Integrations 为新的 OTel-化 Elastic Agent 提供强大的生命周期管理，具体包括：

• 可扩展性：在分布式环境中统一管理 10 万级别 的 Agent。
• 自动升级：阶段性滚动更新，最大程度降低停机时间。
• 监控与诊断：实时状态、失败检测与诊断包下载，提升系统可靠性。
• 基于策略的配置管理：集中控制 Agent 配置，保证各环境一致性。
• 预构建集成：Elastic 提供 470+ 现成集成，轻松接入多种数据源，并将持续新增 OTel 版本，提高大规模部署下的配置效率。

未来 Fleet 还将支持以供应商中立方式监控原生 OTel Collector。

结语

Elastic 拥抱 OpenTelemetry，是开源可观测性发展的重要里程碑。标准化 OTel 后，Elastic 的数据采集策略将更加 开放、可扩展且面向未来。

对开源用户而言，这意味着：

• 不同可观测性工具间的互操作性更强。
• 可以灵活选择遥测后端。
• 社区驱动的开放标准获得更有力的支持。
• 现有 Beats 与 Elastic Agent 用户可 无缝升级至 OpenTelemetry，无需重构流水线。
• OpenTelemetry 用户可 轻松集成 Elastic 全套可观测性方案，无需额外复杂度。

敬请关注 Elastic 在 OpenTelemetry 数据采集领域的更多进展！同时，可参考以下文章：

• Elastic Distributions of OpenTelemetry (EDOT) Now GA
• Dynamic workload discovery on Kubernetes now supported with EDOT Collector
• Introducing the OTTL Playground for OpenTelemetry