文章/答案/技术大牛

发布

社区首页 >专栏 >统一云原生可观测性：Elastic 与 OpenTelemetry 的最佳实践指南

统一云原生可观测性：Elastic 与 OpenTelemetry 的最佳实践指南

原创

点火三周

发布于 2024-10-14 10:05:16

5380

文章被收录于专栏：Elastic Stack专栏Elastic Stack专栏

OpenTelemetry 不仅是开放标准

OpenTelemetry 不仅仅是成为可观测性的开放标准。作为云原生计算基金会（CNCF）下的主要项目之一，OpenTelemetry 得到了大量企业软件供应商和云服务提供商的支持。来自金融、保险、科技等行业的全球企业正在逐步标准化使用 OpenTelemetry。通过 OpenTelemetry，DevOps 团队可以一致地收集和摄取遥测数据，从而为可观测性提供事实上的标准。

Elastic® 正在战略性地将 OpenTelemetry 作为其主要的数据收集架构，用于可观测性和安全性。此外，Elastic 承诺帮助 OpenTelemetry 成为可观测性生态系统中最佳的数据收集基础设施。除了最近向 OpenTelemetry 贡献 Elastic 通用模式（ECS）之外，Elastic 还在进一步加深与 OpenTelemetry 的关系。

自 Elastic 7.14 版本起，Elastic 已经原生支持 OpenTelemetry，可以直接摄取基于 OpenTelemetry 协议（OTLP）的追踪、指标和日志。

在本文中，我们将回顾 Elastic 目前提供的 OpenTelemetry 支持，包括以下内容：

轻松摄取分布式追踪和指标：适用于配置了 OpenTelemetry 代理的 Python、NodeJS、Java、Go 和 .NET 应用程序。
OpenTelemetry 日志的仪器化和摄取：使用多种配置。
开放语义约定：通过 ECS 提供日志和更多内容，这不属于 OpenTelemetry 的一部分。
基于机器学习的 AIOps 功能：如延迟相关性、故障相关性、异常检测、日志峰值分析、预测模式分析、Elastic AI 助手支持等，所有这些功能都适用于原生 OTLP 遥测数据。
按自己的节奏迁移应用程序到 OpenTelemetry：Elastic 的 APM 功能即使在混合使用 OpenTelemetry 和/或 Elastic APM 代理的服务时也能无缝工作。您甚至可以将 OpenTelemetry 仪器化与 Elastic Agent 结合使用。
与 Kubernetes 集群的集成视图和分析：大多数 OpenTelemetry 应用程序都在 Kubernetes 上运行。Elastic 可以在分析基于 OpenTelemetry 的应用程序问题时突出显示与每个服务相关的特定 Pod 和容器。

将 OpenTelemetry 数据摄取到 Elastic

如果您有兴趣了解如何简单地将 OpenTelemetry 追踪和指标摄取到 Elastic，请按照本文中的步骤进行操作。

以下是 Elastic 提供的摄取 OpenTelemetry 数据的选项：

使用 OpenTelemetry Collector

使用 OpenTelemetry Collector 是最常见的配置选项，只需添加两个关键变量。

这些说明使用了一个特定的 opentelemetry-collector 配置来适配 Elastic。基本上，elastic/opentelemetry-demo 项目中的 values.yaml 文件配置了 opentelemetry-collector，使其指向 Elastic APM Server 使用两个主要值：

OTEL_EXPORTER_OTLP_ENDPOINT：Elastic 的 APM 服务器
OTEL_EXPORTER_OTLP_HEADERS：Elastic 授权头

这些值可以在 OpenTelemetry 设置说明中的 APM 集成说明（Integrations->APM）中找到。

嵌入代码中的 OpenTelemetry 代理

如果您打算在代码中使用 OpenTelemetry 库，只需将服务指向 Elastic 的 APM 服务器即可，因为它支持原生 OLTP 协议，无需特殊的 Elastic 转换。

为了更有效地展示这一点并提供一些有关如何使用 OpenTelemetry 的教育，我们提供了两个示例应用程序供您学习：

Elastic 的 OpenTelemetry 演示版本：与其他可观测性供应商一样，我们有自己分叉的 OpenTelemetry 演示版本。
Elastiflix：这个演示应用程序是一个帮助您学习如何在各种语言和遥测信号上进行仪器化的示例。

请查看我们关于使用 Elastiflix 应用程序和 OpenTelemetry 进行仪器化的博客：

Elastiflix 应用程序：指导如何在不同语言中使用 OpenTelemetry 进行仪器化
Python：自动仪器化，手动仪器化
Java：自动仪器化，手动仪器化
Node.js：自动仪器化，手动仪器化
.NET：自动仪器化，手动仪器化

我们还制作了相关主题的 YouTube 视频：

鉴于 Elastic 和 OpenTelemetry 的广泛用户基础，这些资源为任何希望学习 OpenTelemetry 仪器化复杂性的用户提供了丰富的教育资源。

支持 OpenTelemetry 的 Elastic 代理

如果您已经实施了 OpenTelemetry，仍然可以与 OpenTelemetry 一起使用它们。Elastic APM 代理目前能够传输 OpenTelemetry 跨度，作为追踪的一部分。这意味着如果您的应用程序中有任何组件发出 OpenTelemetry 跨度，它将成为 Elastic APM 代理捕获的追踪的一部分。

Elastic 中的 OpenTelemetry 日志

如果您查看 OpenTelemetry 文档，会发现许多语言库仍处于实验状态或尚未实现。根据文档，Java 处于稳定状态。根据您的服务语言以及您对新技术的接受度，存在几种从您的服务和应用程序导出日志并将它们整合到您的可观测性后端的选项。

在之前的一篇博客中，我们讨论了将日志数据正确导入 Elastic 的三种不同配置。博客探讨了 OpenTelemetry 日志的最新状态，并提供了有关可用方法的指导，主要包括以下原则：

在适用的情况下，将服务日志与 OTel 生成的追踪相关联
正确捕获异常
跨追踪、指标和日志的通用上下文
支持 slf4j 键值对（“结构化日志”）
自动附加通过 OTel 行李传递的元数据
使用 Elastic 可观测性后端
无论采用何种方法，在 Elastic 中保持一致的数据保真度

博客中涵盖的三种将应用程序或服务日志与 OTel 追踪和行李相关联的方法包括：

使用嵌入的 OpenTelemetry 仪器化库将服务的日志（与追踪和指标一起）输出到 Elastic，通过 OTLP 协议
将服务的日志写入文件，由 OpenTelemetry Collector 抓取，然后通过 OTLP 协议转发到 Elastic
将服务的日志写入文件，由 Elastic Agent（或 Filebeat）抓取，然后通过 Elastic 定义的协议转发到 Elastic

需要注意的是，相比于方法 (2) 和 (3)，方法 (1) 不涉及在将服务日志摄取到 Elastic 之前将其写入文件。

OpenTelemetry 是 Elastic 的首选模式

Elastic 最近向 OpenTelemetry（OTel）项目贡献了 Elastic 通用模式（ECS），在 OTel 语义约定框架内实现了安全和可观测性数据的统一数据规范。

ECS 是一个开源规范，由 Elastic 用户社区支持开发，用于定义存储在 Elasticsearch® 中的事件数据的通用字段集。ECS 有助于减少数据重复带来的管理和存储成本，提高运营效率。

类似地，OTel 的语义约定（SemConv）也为各种操作和数据指定了通用名称。使用 OTel SemConv 的好处在于，它为 OTel 用户在代码库、库和平台之间提供了统一的命名方案。

ECS 和 OTel SemConv 的融合将有助于推动 OTel 的采用以及可观测性和安全性领域的持续演进和融合。

Elastic 可观测性 APM 和机器学习功能

Elastic 可观测性平台的所有 APM 功能都可以与 OTel 数据一起使用（在我们的博客《使用 OpenTelemetry 实现独立性》中了解更多）：

服务地图
服务详情（延迟、吞吐量、失败事务）
服务之间的依赖关系
事务（追踪）
机器学习相关性（特别是延迟）
服务日志

除了 Elastic 的 APM 和统一的遥测数据视图之外，您还可以使用 Elastic 强大的机器学习功能来减少分析和警报，从而帮助减少平均修复时间（MTTR）。以下是我们的一些基于机器学习的 AIOps 功能：

异常检测：Elastic 可观测性在开启时（参见文档），通过持续建模 OpenTelemetry 数据的正常行为，自动检测异常——学习趋势、周期性等。
日志分类：Elastic 还快速识别 OpenTelemetry 日志事件中的模式，以便您更快采取行动。
高延迟或错误事务：Elastic 可观测性的 APM 功能帮助您发现哪些属性导致事务延迟增加，并识别出区分事务失败和成功的最重要属性。
日志峰值检测器：帮助识别 OpenTelemetry 日志速率增加的原因。通过使用分析工作流视图，轻松找到并调查异常峰值的原因。
日志模式分析：帮助您在非结构化日志消息中找到模式，使您更容易检查数据。

Elastic 允许您按自己的节奏迁移到 OTel

虽然 OpenTelemetry 支持多种编程语言，但其主要功能组件（状态）——指标、追踪和日志——仍处于不同阶段。因此，迁移使用 Java、Python 和 JavaScript 编写的应用程序是一个不错的选择，因为这些语言的指标、追踪和日志（适用于 Java）是稳定的。

对于尚未支持的其他语言，您可以轻松使用 Elastic Agents 进行仪器化，从而在混合模式下运行您的全栈可观测性平台（Elastic agents 和 OpenTelemetry agents）。

以下是一个简单的示例：

上图显示了我们标准的 Elastic Agent 应用程序的一个简单变体，其中一个服务被切换为 OTel——newsletter-otel 服务。但是我们可以根据需要轻松地将每个服务转换为 OTel，具体取决于开发资源的允许情况。

因此，您可以随着特定语言达到稳定状态时，按需迁移到 OpenTelemetry，然后继续将您的应用程序迁移到 OpenTelemetry 代理。

在 Elastic 中集成 Kubernetes 和 OpenTelemetry 视图

Elastic 使用 Elastic Agent 管理您的 Kubernetes 集群，您可以在运行 OpenTelemetry 应用程序的 Kubernetes 集群上使用它。因此，您不仅可以为您的应用程序使用 OpenTelemetry，Elastic 还可以监控相应的 Kubernetes 集群。

Kubernetes 有两种配置：

1. 在 Kubernetes 集群上简单部署 Elastic Agent 守护进程集。 我们在文章《使用 Elastic 可观测性管理您的 Kubernetes 集群》中概述了这一点。这也会将 Kubernetes 的指标和日志推送到 Elastic。

2. 部署 Elastic Agent，不仅包括 Kubernetes 守护进程集，还包括 Elastic 的 APM 集成、安全集成和网络数据包捕获集成，以提供更全面的 Kubernetes 集群可观测性。我们在文章《使用 Elastic 和 OpenTelemetry 实现现代可观测性和安全性》中概述了这一配置。

这两种 OpenTelemetry 可视化示例都使用 OpenTelemetry 演示版，在 Elastic 中，我们将 Kubernetes 信息与应用程序绑定，使您能够从 APM 的追踪中查看 Kubernetes 信息。这提供了一种在排除故障时更为集成的方法。

总结

总之，Elastic 的承诺不仅仅是支持 OpenTelemetry。我们致力于确保客户不仅采用 OpenTelemetry，还能成功使用它。通过我们的解决方案、专业知识和资源，我们旨在提升每个企业的可观测性之旅，将数据转化为推动增长和创新的可操作见解。

开发者资源:Elastiflix 应用程序，指导如何在不同语言中使用 OpenTelemetry 进行仪器化_ Python: 自动仪器化, 手动仪器化 Java: 自动仪器化, 手动仪器化 Node.js: 自动仪器化, 手动仪器化 .NET: 自动仪器化, 手动仪器化 Go: 手动仪器化 OpenTelemetry 的最佳实践