作者：来自 Elastic Nima Rezainia
了解 Elastic Agent 9.3 如何统一 Beats 和 OpenTelemetry（OTel）数据采集，并通过 Elastic Fleet 提供集中化管理。
“OpenTelemetry 的梦想是实现厂商中立、标准化的可观测性。但没有人提到的挑战是：你如何在生产环境中运维数百甚至数千个 collector。”
OpenTelemetry 已经赢得了整个行业的青睐。其采用速度正在加快： CNCF 在 2024 年的 Observability 调查发现， OTel 是该基金会历史上增长最快的项目，而 OTel Collector 的下载量已达数亿次。它的价值主张非常有吸引力：一次编写 instrumentation，随处部署，避免厂商锁定。
但每一个平台团队在进入生产环境后都会发现一个问题： collector sprawl（采集器泛滥）问题。数百个 collector 实例分布在不同区域、 Kubernetes 命名空间以及裸金属主机上。配置漂移逐渐出现。一次升级需要在一组相互独立的进程中协调完成。安全补丁需要有人手动逐个发布。而你几乎无法可视化了解哪些 collector 正在运行、健康，或已经卡住。
这正是 “部署 OpenTelemetry” 和“在规模化环境中运维 OpenTelemetry”之间的差距。通过 Elastic 9.3， Elastic Agent 完全弥合了这一差距。 Elastic Agent 现在构建在 Elastic 的 OpenTelemetry Collector 发行版（ EDOT）之上，并且在 Fleet 的管理下，为平台团队提供了一个统一的控制平面，用于配置、更新和监控其环境中的所有 OTel collector —— 同时仍然兼容他们已经依赖的基于 Beats 的集成。
Collector 泛滥问题及其重要性
OpenTelemetry 的成功为许多组织带来了隐性的运维负担。各个团队分别为自己的服务采用 collector：这里收集日志，那里收集指标，为新的微服务构建自定义 pipeline。如果没有集中化的管理层，这些 collector 就会变成独立的 “雪花”：各自拥有配置文件、升级周期和故障域。
其结果是可以预见的。配置漂移导致不同 collector 运行着同一 pipeline 的不同版本，从而生成细微不兼容的数据。合规团队会问：“请告诉我所有数据采集的位置以及数据流向哪里”，而现实的答案往往是一个已经过时的电子表格。
这并不是一个小众问题。 Gartner 对企业可观测性项目的分析持续表明，运维开销是阻碍 OTel 从初始试点扩展的首要障碍。技术本身没有问题，缺失的是在规模化环境中进行管理的工具。
Elastic Agent 如何成为 OTel Collector
要理解这一变化的重要性，需要了解 Elastic Agent 过去是什么，以及现在变成了什么。
Elastic Agent 作为一个监督进程：在 9.3 版本之前，它管理着一组独立的 Beats 子进程（ Filebeat、 Metricbeat、 Winlogbeat 等），每个进程都有自己的输入/输出生命周期，并消耗各自的内存资源。 Agent 负责协调它们，但本质上仍然是多个独立守护进程运行在一个父进程之下。
在 9.3 中，这一模型发生了变化。 Elastic Agent 本身现在就是一个 EDOT Collector 实例 —— 这是 Elastic 基于上游 OTel Collector 构建的强化版、可用于生产的发行版。这一架构转变带来了三个重要影响。
首先，进程模型大幅简化。不再是一个监督进程管理多个子进程生命周期，而是一个单一的 EDOT Collector 进程。这意味着更小的内存占用，更少的独立故障点，以及更少需要监控健康状态和性能的进程。
其次， Beats 功能被保留而不是被抛弃。 Elastic 没有强制进行破坏性迁移，而是引入了 Beats Receivers：将 beat 的输入和处理器重新打包为原生的 OTel receiver 组件。例如， Filestream 输入通过 filebeatreceiver 启用。你当前编写的 Filebeat YAML 配置会在运行时自动转换为对应的 EDOT receiver 配置。现有的集成、仪表板和 ingest pipeline 无需修改即可继续使用。
第三， Agent 现在成为 OTel 生态中的一等公民。它原生支持 OTLP，运行标准的 OTel receivers，并且可以与现代可观测性 pipeline 中的其他 OTel 兼容工具协同工作。
使用 Fleet 进行集中管理：配置、生命周期和可见性
上述架构转变本身就具有很高的价值。但当它与 Elastic Fleet（ Elastic Agents 的集中化管理控制平面）结合时，就会带来变革性的效果。
Fleet 为平台团队和 SRE 团队提供了一个统一的控制台，用于管理其环境中的每一个 Elastic Agent（以及对应的每一个 EDOT Collector 实例）。其能力可以分为三大类：配置管理、生命周期管理以及全局可观测性。
规模化配置管理
通过 Fleet，你可以定义一个 Agent Policy —— 用声明式的方式描述一个 collector 应该执行什么任务。它需要收集哪些数据？通过哪些 receivers？将数据导出到哪里？该策略只需在 Fleet 的 UI（或通过其 API）中编写一次，然后会自动下发到所有加入该策略的 agent。只要策略发生变化，所有相关的 collector 都会自动接收更新。无需 SSH，无需维护 Ansible playbook，也不会出现配置漂移。
Fleet 会将策略推送到任何环境中已注册的 agent。 agent 会回传心跳和健康数据，从而提供整个环境中每个 collector 的实时清单。
生命周期管理：升级、注册和修复
Fleet 管理带来的最重要运维优势之一是生命周期控制。通过 Fleet，升级 collector 成为一种策略操作：选择目标版本，选择范围（所有 agent、某个策略组或金丝雀子集），然后点击执行。 Fleet 会编排滚动升级，按 agent 跟踪状态，并立即展示失败情况。
这从根本上改变了安全响应方式。当 OTel Collector 二进制出现漏洞时，打补丁变成一个以分钟为单位的 Fleet 操作，而不是需要数天、通过 SSH 登录每台主机逐一执行的变更流程。
Fleet 还负责注册和注销。当新主机加入你的基础设施时，可以根据标签或部署工具自动注册到合适的策略中。对于已下线主机上的 agent，可以从 Fleet 清单中移除，从而确保你的可观测性视图与实际基础设施保持一致。
对 collector 的全局可观测性
每一个由 Fleet 管理的 Elastic Agent 都会上报自身的监控遥测数据： CPU 和内存使用、事件吞吐量、错误率、 pipeline 延迟。这些数据会进入 Elastic，并在 Fleet UI 中展示，让你可以查看整个环境中所有 collector 的实时状态，而不仅仅是你当前关注的部分。
第一次，“我的可观测性 pipeline 有多健康？”这个问题可以通过全局实时数据来回答。你可以提前发现那些停止发送数据的 agent、资源消耗异常的 agent，以及在队列处理中落后的 agent——在这些问题演变成监控数据缺失之前。
在不久的将来，这一能力也会扩展到非 Fleet 管理的 agent（即 standalone）以及其他厂商提供的第三方 OTel collectors。这些 collector 可以通过其他方式进行配置，但仍然可以在 Fleet 中进行监控——无论是资源使用情况还是组件 pipeline 的健康状态。
混合 Agent：同时处理 Beats 数据和 OTel 数据
9.3 引入的一个非常重要的能力是 Elastic 所称的 Hybrid Agent：一种可以在同一个 pipeline 中同时运行基于 Beats 的 receivers 和原生 OTel receivers 的 Elastic Agent。这不会改变现有部署。
这对实际落地非常关键。大多数在 2025 和 2026 年开始采用 OTel 的组织，并不是从零开始。他们已经在基于 Beats 的集成上投入多年：使用 Filebeat 收集日志，使用 Metricbeat 收集主机指标，以及在 Elasticsearch 中构建了自定义 ingest pipelines，用于将数据标准化并转换为 ECS（ Elastic Common Schema）格式。这些集成中沉淀的业务价值（仪表板、告警、关联分析逻辑）无法被轻易舍弃，只为了“全面转向 OTel”。
Hybrid Agent 通过让两种体系共存来解决这个问题。例如，在同一个 agent policy 中，你可以同时配置：
- 一个 filebeatreceiver，用于以 ECS 格式采集应用日志，并通过现有 ingest pipeline 路由到原有的数据流
- 一个原生 OTel filelog receiver，用于采集来自使用 OTel SDK 的新服务的原生 OTel 遥测数据，并存储到原生 OTel 数据流中，而无需经过 ingest pipeline
- 一个 OTel hostmetrics receiver，用于按照语义规范收集系统指标，并与现有基于 Metricbeat 的系统指标同时存在
这两条路径是相互独立的。基于 Beats 的 receiver 数据会通过 ingest pipelines 处理，并以 ECS 格式存储到数据流中，和以往完全一致。原生 OTel 数据遵循 OTel 语义规范，直接存储到原生 OTel 数据流中，绕过 ingest pipelines。你现有的仪表板和告警可以继续使用，而新的原生 OTel 工作负载则可以获得完整的 OTel 体验。同一个 agent，同一个 Fleet policy，同一个管理控制台。
这种共存机制为每个平台团队最终都会面对的问题提供了现实答案：“我们想正确地采用 OTel，但不能破坏已有系统。” Hybrid Agent 允许你按服务逐步迁移，并按照你的节奏推进。
集成目录：将配置转化为一键操作
规模化配置管理的效果取决于配置本身的质量。 Elastic 的集成目录 —— 包含超过 500 个 package，覆盖从 NGINX、 PostgreSQL 到 AWS CloudTrail 和 Kubernetes 的各种系统——自然扩展到了 Hybrid Agent 模型。
从 9.3 开始，该目录在现有基于 Beats 的集成之外，还包含 OTel 集成 package。每个 OTel package 包含两个部分：
- 一个 Input package：对应 OTel receiver 的配置（ receivers、 processors、 pipeline 连接方式），可直接应用于 Hybrid Agent policy
- 一个 Content package：与应用相关的资源，例如预构建的仪表板、告警、索引模板和保存的查询，全部基于 OTel 语义规范数据进行优化
当运维人员在 Fleet 中向 Agent Policy 添加一个 OTel 集成时，receiver 配置会被推送到所有已注册的 agent。当这些 agent 开始采集数据并写入 Elasticsearch 时，Content package 中的资源会根据接收到的数据中的元数据自动安装。在你还没来得及寻找仪表板时，它已经准备好了。
同一个 policy 可以同时包含 OTel 集成和传统的 Beats 集成。一个真实场景中的 agent policy 可能会同时通过 OTel hostmetrics receiver 采集系统指标，通过 filebeat receiver 采集应用日志，并通过 OTLP 采集 APM 数据——全部来自同一个 policy，由 Fleet 管理，并在统一的 Kibana 体验中可见。
关于如何为 NGINX 数据采集实现这一流程的技术演示可以参考相关文档。目前 Elastic Agent 的管理仍然通过现有的 Fleet 协议完成，但在不久的将来将迁移到 OPAMP，从而使 Fleet 也能够管理第三方 OTel collectors。
对于运行在尚未被 Elastic 操作系统支持矩阵覆盖的平台上的组织，可以使用第三方 OTel Collectors（例如 Red Hat 的 OpenShift 原生 collector）通过 OTLP exporter 将数据发送到 Elastic，并与其环境中的其他 collectors 一起进行统一观测。
实际意义：一个迁移案例
假设一个中型平台团队在三个区域运行着 200 台 Linux 主机，目前使用 Elastic Agent 8.x，并结合 Filebeat 和 Metricbeat 集成。他们的新服务正在使用 OTel SDK 进行埋点，并希望未来统一采用 OTel，同时又不影响现有的监控覆盖。
通过使用 Fleet 管理升级到 9.3，他们现有的 agent 会自动变为 Hybrid Agent。他们的 Filebeat 和 Metricbeat 配置会在内部转换为 Beats receiver 配置，并继续运行而无需修改。现有的仪表板仍然正常显示， ingest pipelines 继续执行，一切都不会中断。
随后，他们为每个新服务在 Fleet policy 中添加 OTel 集成 package。使用 OTel 进行埋点的微服务开始发送 OTLP 数据，这些数据由同一 agent 中的原生 OTel receivers 接收。原生 OTel 仪表板会自动在 Kibana 中出现。现在，他们可以在一个地方拥有两种数据体系，通过一个控制台管理，并在一个界面中统一查看。
在接下来的几个季度中，随着其余服务中基于 Beats 的集成被集成目录中的 OTel 替代方案逐步取代，他们可以逐个进行迁移：只需在 Fleet 中更新 Agent Policy，即可在全部 200 台主机上同时完成变更，而无需直接操作任何一台主机。
展望未来
Elastic 已经做出了明确的架构选择： OpenTelemetry 是可观测性数据采集的未来，而应对这一未来的正确方式，不是构建一个与现有体系并行的 OTel 工具，而是将现有体系演进为 OTel。 Hybrid Agent 和 EDOT Collector 正是这一决策的产物。
Fleet 的集中管理则是让这一决策能够在规模化环境中落地的运维基础层。 OpenTelemetry 提供了标准化、厂商中立的 instrumentation，而 Fleet 提供了运维控制平面，使你能够像管理生产基础设施一样管理这些 collectors，而不是把它们当作分散在各处的 YAML 配置文件。
collector sprawl 问题是可以解决的。答案是一个受管控的、基于策略驱动、具备集中可观测性的 EDOT Collector 集群，而在 Elastic 9.3 中，这一方案已经可以在生产环境中使用。
