作者来自 Elastic Nima RezainiaElastic Agent 9.3 通过一个 OTel Collector pipeline 发送日志、指标和追踪数据在一个由 Fleet 管理的 agent 中同时运行 Beats integrations 和原生 OTel sources。Elastic Agent 9.3 使用更少的内存并且开箱即用地接受来自任何兼容 OpenTelemetryOTel的 source 的数据。在底层旧的 Beats 子进程架构已经被一个基于 Elastic Distribution of OpenTelemetryEDOTCollector 构建的、针对日志、指标和追踪数据的单一 OTel 原生 pipeline 所取代。你现有的 integrations、dashboards、Fleet policies、alerting rules 和 ingest pipelines 都无需更改即可继续工作。Elastic Agent 9.3 的变化底层原生 OTel Collector此前Elastic Agent 充当 supervisor process启动基于 Beats 的子进程例如 Filebeat 或 Metricbeat。从 9.3 开始这一架构已经被替换。Elastic Agent 本身现在基于 EDOT Collector 构建使其在底层成为一流的 OTel Collector同时保留原有功能。这一架构转变的主要优势包括更低的资源占用更少的子进程意味着显著降低的内存开销和更简单的部署模型。在未来版本中这一资源占用还将进一步降低。统一的 telemetry pipeline日志和指标通过单一的、基于标准的 OTel pipeline 流动追踪数据也是如此。生态系统互操作性Elastic Agent 现在可以开箱即用地接收来自任何兼容 OTel 的 source 的数据。它也可以配置为向兼容 OTel 的 destination 发送数据。与 OTel 生态系统保持一致随着 OTel 生态系统通过新的 receivers、processors 和 exporters 不断成熟Elastic Agent 部署可以自动获得这些能力。当你从 9.3 及更高版本部署或升级 Elastic Agent 时你部署的就是一个 OpenTelemetry Collector。EDOT 是技术基础Elastic Agent 是产品。现有 Beats 配置如何在 OTel Collector pipeline 中运行Elastic 引入了 Beats Receivers它们是可以在新的 OTel Collector pipeline 中原生执行的 Beat inputs 和 processors。对于你的团队和客户而言这意味着现有的elastic-agent.yml配置无需修改。由 Fleet 管理的 agent 会在内部自动将 policy 配置转换为 OTel 格式。所有 integrations、dashboards、ingest pipelines 和 alerting rules 都会继续像以前一样正常运行。通过 Beats Receivers 写入的数据仍然会进入与之前相同的 data streams。升级到 9.3 是透明的因为它使用相同的 inputs并产生相同的 outputs。在一个 Elastic Agent 中运行 Beats 和 OTel Collector pipelines新的 Elastic Agent 是一个 collector可以在单个部署中同时运行传统的基于 Beats 的采集以及原生 OTel pipelines。一个 agent policy 可以通过 Beats Receivers 采集经过 Elastic Common SchemaECS规范化的数据同时从经过 OTel-instrumented 的应用和基础设施中摄取原生 OpenTelemetry ProtocolOTLP数据。同一个 agent policy 可以在所有 telemetry 导出之前应用 OTel processing stages。Elastic catalog 中的 OTel integrations 可以添加到任何 agent policy 中。当摄取原生 OTel 数据时Elastic 会自动安装相关的 dashboards 和 alerts以及必要的 content packs无需任何手动设置。Elastic Agent 和 EDOT 之间是什么关系你可能已经熟悉作为独立产品的 EDOT即 Elastic Distribution of OpenTelemetry Collector。随着这一架构变化EDOT 成为了现在驱动 Elastic Agent 的技术基础而不再是用户需要单独跟踪或部署的独立产品。今后Elastic Agent 是受支持的、可由 Fleet 管理且功能完整的产品。对于特定的细分场景无法安装完整版本 Elastic Agent 的环境独立部署仍然可用但对于绝大多数用户而言这并不是推荐的路径。Elastic Agent 部署选项由 Fleet 管理 vs. 独立运行由 Fleet 管理的 Elastic Agent独立运行的 Elastic AgentFleet 生命周期管理是Beats Receivers是Elastic Defend是Cloud Security是Profiler 支持是OTel 原生 pipeline是最适合大多数部署场景升级到 Elastic Agent 9.3 时需要更改任何内容吗对于目前正在运行 Elastic Agent 的用户来说升级到 9.3 无需更改配置或 integrations也无需更改 workflows。对于正在评估采用 OTel 的客户Elastic Agent 现在提供了一个完全受支持、可用于生产环境的 OTel Collector并具备 Fleet 管理和丰富的 integrations同时还提供 Elastic 完整的支持矩阵而这一切都不需要单独部署 OTel。借助 Elastic Agent 9.3Elastic 的数据采集已经完全原生支持 OpenTelemetry。Elastic Agent 现在就是一个 OpenTelemetry Collector。你目前拥有的一切仍然可以正常运行同时你还可以获得 OTel 的全部能力。原文https://www.elastic.co/observability-labs/blog/opentelemetry-collector-elastic-agent
