使用原生 OpenTelemetry 解锁各种可能性：优先考虑可靠性，而不是专有限制

作者：来自 Elastic Bahubali Shetti•Miguel Luna

Elastic 现在支持使用 OTel Operator 在 Kubernetes 上部署和管理 Elastic Distributions of OpenTelemetry (EDOT)。SRE 现在可以访问开箱即用的配置和仪表板，这些配置和仪表板旨在通过 Elastic Observability 简化收集器部署、应用程序自动检测和生命周期管理。

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

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

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

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

Elastic 的 OpenTelemetry-first 架构是 100% OTel 原生的，完全保留了 OTel 数据模型，包括 OTel 语义约定和资源属性，因此你的可观测性数据仍符合 OpenTelemetry 标准。Elastic 中的 OTel 数据还向后兼容 Elastic Common Schema (ECS)。

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

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

利用 Elastic Distributions of 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 项目的最新进展保持一致，从而加强其对开放标准和社区驱动开发的承诺。

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

查看我们最近的博客，了解如何进行设置。

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

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

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

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

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

3. 利用 OTel 数据和 Elasticsearch 简化采集架构

Elastic 的采集架构允许用户使用 EDOT Collector 将跟踪数据直接转发到 Elasticsearch，从而最大限度地降低基础设施开销，无需使用 Elastic APM 服务器。此方法：

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

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

Elastic 对开源和 OpenTelemetry 的持续承诺

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

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

客户现在可以采用开放标准，并享受与其环境无缝集成的开放、可扩展平台的优势。最终结果？降低成本、提高可视性并摆脱供应商的依赖。