OpenTelemetry (OTel) 正在成为数据摄取的标准，因为它提供了一种与供应商无关的方式来摄取所有遥测信号的数据。Elastic Observability 正在引领 OTel 的发展，并发布以下公告

原生 OTel 完整性： Elastic 现在 100% 原生支持 OTel，原生保留 OTel 数据，无需数据转换。这消除了 SRE 处理繁琐的模式转换和开发自定义视图的需求。所有 Elastic Observability 功能（如实体发现、以实体为中心的见解、APM、基础设施监控和 AI 驱动的问题分析）现在都可以无缝地与原生 OTel 数据配合使用。
通过 Elastic OpenTelemetry 发行版 (EDOT)实现强大的端到端基于 OTel 的 Kubernetes 可观察性： Elastic 现在支持通过 OTel Operator 在 Kubernetes 上部署和管理 EDOT，从而实现简化的 EDOT 收集器部署、应用程序自动检测和生命周期管理。借助开箱即用的基于 OTel 的 Kubernetes 集成和仪表板，SRE 可以即时、实时地查看集群和应用程序的指标、日志和跟踪，而无需手动配置。

对于组织而言，这表明我们致力于开放标准、简化数据收集以及从原生 OpenTelemetry 数据中提供见解。将 Elastic Observability 的强大功能引入您的 Kubernetes 和 OpenTelemetry 部署，以实现最大程度的可见性和性能。

具有深入数据分析的完全原生 OTel 架构

Elastic 的 OpenTelemetry 优先架构 100% 原生支持 OTel，完全保留 OTel 数据模型，包括 OTel 语义约定和资源属性，因此您的可观察性数据仍符合 OpenTelemetry 标准。Elastic 中的 OTel 数据还与 Elastic Common Schema (ECS) 向后兼容。

SRE 现在可以获得资源的整体视图，因为 Elastic 通过 OTel 资源属性准确识别实体。例如，在 Kubernetes 环境中，Elastic 会识别容器、主机和服务，并将这些实体连接到日志、指标和跟踪。

一旦 OTel 数据进入 Elastic 的可扩展矢量数据存储中，Elastic 的功能（如 AI 助手、基于零配置机器学习的异常检测、模式分析和延迟关联）使 SRE 能够快速分析和查明生产环境中潜在的问题。

通过 Elastic OpenTelemetry 发行版 (EDOT) 实现 Kubernetes 见解

EDOT 通过自动化入门和预配置仪表板减少了手动工作。通过 EDOT 和 OpenTelemetry，Elastic 使任何规模的组织都可以轻松访问 Kubernetes 监控。

EDOT 与 Elasticsearch 配对，可以存储所有信号类型（日志、指标、跟踪，以及即将推出的分析），同时保留必要的资源属性和语义约定。

Elastic 的原生 OpenTelemetry 解决方案使客户能够快速从其数据中提取见解，而无需管理复杂的用于摄取数据的基础设施。Elastic 自动化可观察性组件的部署和配置，以提供专注于易用性和可扩展性的用户体验，使其非常适合大规模环境和各种行业需求。

让我们来看看 Elastic 的 EDOT 如何实现 Kubernetes 环境的可见性。

1. 通过生命周期管理和自动检测实现简单的 3 步 OTel 摄取

Elastic 利用上游 OpenTelemetry Operator 自动化其 EDOT 生命周期管理（包括部署、扩展和更新），使客户可以专注于查看其 Kubernetes 基础设施和应用程序，而不是他们用于数据收集的可观察性基础设施。

该 Operator 与 EDOT Collector 和语言 SDK 集成，以提供一致的、与供应商无关的体验。例如，当客户部署新应用程序时，他们无需手动配置各种语言的检测；OpenTelemetry Operator 通过自动检测来管理此操作，如上游 OpenTelemetry 项目所支持的那样。

这种集成通过确保在整个 Kubernetes 环境中实现一致的应用程序检测来简化可观察性。Elastic 与上游 OpenTelemetry 项目的合作加强了这种自动化，使用户能够受益于 OpenTelemetry 生态系统的最新更新和改进。通过依赖 OpenTelemetry Operator 等开源工具，Elastic 确保其解决方案与 OpenTelemetry 项目的最新进展保持一致，从而加强其对开放标准和社区驱动开发的承诺。

上图显示了 operator 如何部署多个 OTel 收集器，从而帮助 SRE 为特定应用程序和基础设施部署单独的 EDOT 收集器。此配置提高了 OTel 摄取的可用性，并通过 OTLP 将遥测数据直接发送到 Elasticsearch 服务器。

请查看我们最近关于如何进行设置的博客.

2. 开箱即用的基于 OTel 的 Kubernetes 集成和仪表板

Elastic 通过打包 Kubernetes 可观察性的所有必要接收器、处理器和配置，为 OTel 收集器提供基于 OTel 的 Kubernetes 配置。这使用户能够自动收集、处理和分析 Kubernetes 指标、日志和跟踪，而无需单独配置每个组件。

OpenTelemetry Kubernetes 收集器组件提供了基本的构建块，包括用于集群指标的 Kubernetes 接收器、用于详细的节点和容器指标的 Kubeletstats 接收器，以及用于数据转换和丰富的处理器。通过打包这些组件，Elastic 提供了一个统包解决方案，该解决方案简化了 Kubernetes 可观察性，并消除了用户设置和配置单独的收集器或处理器的需要。

这种预打包方法（包括基于 OTel 的 Kibana 资产，如仪表板）使您可以专注于分析可观察性数据，而不是管理配置细节。Elastic 的统一 OpenTelemetry 体验确保用户可以利用 OpenTelemetry 的全部潜力，而无需深厚的专业知识。无论您是监控资源使用情况、容器运行状况还是 API 服务器指标，用户都可以通过 EDOT 获得全面的可观察性。

有关 OpenTelemetry Kubernetes Collector 组件的更多详细信息，请访问 OpenTelemetry Collector 组件。

3. 使用 OTel 数据和 Elasticsearch 实现的精简摄取架构

Elastic 的摄取架构通过允许用户使用 EDOT Collector 将跟踪数据直接转发到 Elasticsearch，从而最大限度地减少了基础设施开销，无需 Elastic APM 服务器。这种方法

降低了维护额外基础设施相关的成本和复杂性，使用户能够以更少的资源部署、扩展和管理其可观测性解决方案。
允许将所有 OTel 数据、指标、日志和跟踪数据摄取并存储在 Elastic 的单一向量数据库存储中，从而可以使用 Elastic 的 AI 驱动功能进行进一步分析。

现在，SRE 可以减轻运营负担，同时获得 Elastic 提供的高性能分析和可观测性洞察。

Elastic 对开源和 OpenTelemetry 的持续承诺

随着 Elasticsearch 再次完全以 AGPL 许可开源，这一变化加强了我们对开放标准和开源社区的坚定承诺。这与 Elastic 的以 OpenTelemetry 为先的可观测性方法保持一致，其中 Elastic OpenTelemetry 发行版 (EDOT) 简化了 OTel 摄取和模式自动检测，为 Kubernetes 和应用程序遥测提供实时洞察。

随着用户越来越多地采用 OTel 作为其可观测性的模式和数据收集架构，Elastic 的 OpenTelemetry 发行版 (EDOT)（目前为技术预览版）增强了标准 OpenTelemetry 功能，并改进了故障排除，同时还充当商业支持的 OTel 发行版。EDOT 与 Elastic 最近为 OpenTelemetry 贡献的 Elastic Profiling Agent 和 Elastic Common Schema (ECS) 一起，加强了 Elastic 对将 OpenTelemetry 确立为行业标准的承诺。

现在，客户可以拥抱开放标准，并享受与他们的环境无缝集成的开放、可扩展平台的优势。最终结果？降低成本、提高可见性和实现供应商独立性。

开始使用 Elastic 可观测性和 EDOT

准备好使用带有 EDOT 收集器和 SDK 的 OTel Operator，了解 Elastic 如何在 APM、Discover、分析和开箱即用仪表板中使用摄取的 OTel 数据了吗？

如果您有自己的应用程序并且想要使用自动检测配置 EDOT 应用程序，请阅读以下关于 Go、Java、PHP、Python 的博客

通过原生 OpenTelemetry 解锁无限可能：优先考虑可靠性，而非专有局限性