作者：来自 Elastic Frederic Maussion

混合 Elastic Agent：采用 OpenTelemetry 最务实的路径

OpenTelemetry 正在迅速成为现代可观测性的标准基础。组织希望获得其开放生态系统、统一模型，以及厂商中立的埋点 —— 但将一个成熟的生产环境迁移到 OTel 通常并不简单。

大多数团队已经依赖经过实战验证的日志、指标和安全信号管道。他们拥有多年调优的仪表板、围绕现有数据流构建的运维实践，以及不允许中断的关键任务系统。

这意味着问题不再是 “为什么选择 OpenTelemetry？”，而是 “我们如何在不破坏现有可用系统的情况下到达那里？”

Elastic Observability 通过混合摄取提供了一种在不干扰现有数据和仪表板的情况下摄取遥测数据的方法。该能力在 Elastic 9.2 中发布，它是一种低摩擦方式，可在 Fleet 的集中管理下，将 OTel 接收器与现有的原生 Elastic 集成并行使用。

这种混合方式提供了当今最务实、在运维上也最安全的 OTel 采用路径之一。

挑战：在不干扰现有系统的情况下采用 OTel

对许多组织来说，采用 OTel 的路径受到以下现实因素的影响而变得复杂：

• 已建立的日志管道，支撑着关键告警
• 不易重新进行埋点的遗留基础设施
• 基于 Elastic 原生数据集构建的现有仪表板和可视化
• 团队成员对 OTel 的经验水平不一
• 风险约束使得大规模变更难以推进

在长期来看，统一到 OTel 是正确的方向，但一次性替换所有内容既不现实，也不可取。

团队需要一种方式，能够逐步将 OTel 引入现有环境，同时保持连续性、可靠性，以及集中治理。

Elastic Agent 9.2+：作为通往未来的桥梁的混合摄取

Elastic Agent 现在支持两种完全受支持的摄取路径，并且都运行在同一个统一的 agent 中：

• Elastic 原生集成
  • 非常适合日志和主机级遥测，提供成熟的仪表板、告警以及 ECS 映射。
• OpenTelemetry 输入集成（ OTel 接收器 ）
  • 由上游 OTel Collector 组件驱动，并直接通过 Fleet 进行管理。

关键在于：

你可以在同一个 agent 上，同时使用这两种方式。

这种混合摄取模型使团队能够：

• 继续使用 Elastic 原生集成来采集日志
• 开始通过 OTel 接收器采集指标或追踪
• 通过 Fleet 保持完整的集中控制
• 在合适的时间和位置引入 OTel
• 避免运行并行 agent 或重复的数据管道

这是一种演进方式 —— 而不是替换 —— 你的可观测性策略。

一个实用示例：在保留现有管道的同时添加 OTel 输入

想象一个系统，其中 NGINX 日志已经通过 Elastic 原生集成进行处理。这些管道驱动着仪表板、审计以及关键告警，任何中断都不可接受。

与此同时，你的平台团队希望使用 OpenTelemetry 来统一指标和服务遥测。

通过 Elastic Agent 的混合摄取，这两个目标可以同时实现：

• 在 Fleet 中保留现有的日志集成
• 添加一个 OTel 输入集成（例如 OTel nginxreceiver ）
• Fleet 将这两者一起部署到同一个 Elastic Agent 中
• 通过单一的管理控制台，在整个基础设施中大规模完成部署
• 日志和 OTel 指标并行流入 Elasticsearch

无需重新埋点。无需重复 agent。不会丢失历史可见性。无需新的运维工具。无需外部部署工具。

无论组件是 Web 服务器、反向代理、数据库、 JVM 运行时，还是已经使用 OTel 进行埋点的自定义服务，工作流程都是相同的。

为什么这种混合方式在战略上很重要

混合摄取不仅仅是一种技术能力 —— 它还是推动 OpenTelemetry 转型的组织级赋能手段。

渐进式迁移，无需停机

团队可以按照自己最舒适的节奏开始采用 OTel 。现有的采集信号保持稳定， OTel 指标或日志逐步加入。

Fleet 仍然是你的单一控制平面

即使 OTel 成为你摄取策略的一部分， Fleet 仍然负责管理：

• agent 生命周期
• 策略管理
• 版本升级
• 诊断与监控

跨团队的一致语义

通过 EDOT 采用 OTel 接收器，有助于在微服务、基础设施和应用之间统一遥测模型。

OTel 成为通用语言 —— Elastic 成为可扩展的后端。

面向未来的灵活性

当某个团队需要高级 OTel 功能、自定义管道、自定义处理器或额外的 exporter 时，他们可以构建自己的 EDOT 自定义 collector 版本，并在 hybrid 模式下将其用于 elastic-agent 。

这使你能够在不放弃 Elastic Agent 运行时的情况下，实现深度定制。

无厂商锁定 —— 完整的生态系统对齐

混合摄取 直接使用上游 OpenTelemetry 组件。这强化了组织在跨团队标准化可观测性时所偏好的开放、厂商中立生态系统，同时又能获得 Elastic 的支持。

关于 Standalone 模式？（高级用例）

虽然由 Fleet 管理的混合摄取 可以满足大多数用户的需求，但处于混合模式下的 Elastic Agent 也支持独立部署，并具备与托管版本相同的功能。

• 支持原生集成
• 完全控制 OTel 接收器、处理器和 exporter
• 以 Elasticsearch 作为后端输出

这对正在测试高级 OTel 部署或构建自定义遥测策略的平台团队来说尤其有用。

但这仍然是可选的 —— 托管体验依然是默认路径。

结论：通往 OpenTelemetry 的现代化、灵活路径

迁移到 OpenTelemetry 是一段旅程，而不是一次切换。通过 混合摄取， Elastic 为希望逐步采用 OTel、同时保持运维连续性的组织，提供了一条现实、可扩展且低风险的路径。

Elastic Agent 9.2+ 使团队能够：

• 保留可靠的日志集成
• 无缝引入 OTel 输入
• 通过 Fleet 统一管理一切
• 降低复杂性和运维开销
• 以合适的节奏扩展到 OTel
• 持续对齐开放标准和最佳实践

它将两者的优势 —— Elastic 原生的丰富能力 与 OTel 标准的灵活性 —— 融合到一个 agent 和统一的运维模型中。

Hybrid 不是一种权宜之计。它是连接你当前可观测性平台与下一阶段目标之间的战略桥梁。

技术操作指南：在 Fleet 中部署混合 Elastic Agent + EDOT

在结束之前，让我们看看实际操作中会是什么样子。概念上的优势很重要，但许多团队希望看到通过 Fleet 部署时混合摄取的实际工作方式。

下面的示例演示了一个简单、可投入生产的设置，使用 Elastic Agent 9.2，将原生集成和 OTel 输入集成组合在同一个 agent 中，这种方法可以应用到环境中的任何服务。

以下是逐步指南，展示如何在 Fleet 管理的混合模式下部署 Elastic Agent 9.2，以 OTel nginxreceiver 为具体示例。此方法适用于任何具有 OTel 接收器的服务（Redis、HAProxy、Kafka、JVM 等）。

要求

• Elastic Stack 9.2+
• Elastic Agent 9.2+
• 在 Kibana 中配置 Fleet
• 运行你的工作负载的主机（本例中为 NGINX）
• NGINX stub_status 端点或任何等效的 OTel 指标端点
• 具有摄取权限的 API key

创建或选择 Agent 策略

1. 在 Kibana → Management → Fleet → Agent policies
2. 创建一个新策略： nginx-o11y
3. 启用系统监控（推荐）
4. 保存

将 Elastic Agent 注册到策略中

在策略（policy）页面：

1. 点击 Add agent
2. 选择你的操作系统
3. 复制安装命令
4. 运行：

sudo elastic-agent install \
  --url=<FLEET_URL> \
  --enrollment-token=<ENROLLMENT_TOKEN>

你很快就会在 Fleet 中看到 agent 显示为 Healthy。

添加原生集成（日志）

1. 在 Fleet 中，进入 Integrations。
2. 搜索 NGINX
3. 点击 Add NGINX
4. 选择你的 nginx-o11y 策略
5. 仅启用日志采集（access + error logs）
6. 保存并部署

验证日志采集

在 Kibana，进入 Analytics → Discover 并搜索：

data_stream.dataset : "nginx.access" or "nginx.error"

或者打开内置仪表板：

Analytics → Dashboards → [Logs Nginx] Access and error logs

通过 OTel NGINX 接收器采集 NGINX 指标

Elastic Agent 9.2+ 允许 Fleet 部署 OTel 输入集成。
本场景通过 Fleet 管理的集成，使用 OpenTelemetry nginxreceiver。

安装 NGINX OpenTelemetry 集成内容

1. 在 Kibana，进入 Management → Fleet → Integrations。
2. 搜索 NGINX OpenTelemetry Assets
3. 点击 Add Integration

安装 NGINX OpenTelemetry 输入集成

1. 在 Kibana，进入 Management → Fleet → Integrations。

2. 搜索 NGINX OpenTelemetry Input Package

3. 点击 Add Integration

4. 将其分配到你的 agent nginx-o11y 策略

提供 NGINX 状态页面端点：

• Endpoint: http://localhost/status
• Collection interval: 10s

点击 Add integration

验证 OTel 指标

1. 进入 Analytics → Dashboards。
2. 打开：[Metrics Nginx OTEL Overview] 仪表板

你应该能看到诸如 active connections、writes、reads、waiting 和 request counts 等指标。

总结

这个示例展示了使用 Elastic Agent 9.2 时，混合摄取变得多么简单。通过在单一、集中管理的策略中组合原生集成和 OTel 接收器，你可以灵活地在最有价值的地方采用 OpenTelemetry，而不会干扰现有管道或增加运维负担。

无论你是将这种模式扩展到其他服务、尝试其他 OTel 接收器，还是在整个 fleet 中大规模部署，部署模型都是一致、可重复且可投入生产的。

更多信息及 Elastic Observability 的其他创新，请查看：

• 了解 Elastic 如何通过 OpenTelemetry 演进数据摄取
• 学习 OpAMP 如何实现 OpenTelemetry SDK 的集中配置
• 探索 Streams 如何重塑 AI 驱动的日志调查工作流

原文：https://www.elastic.co/observability-labs/blog/hybrid-elastic-agent-opentelemetry-integration