作者：来自 Elastic Roger Coll

了解 Elastic 如何致力于支持用户使用 OpenTelemetry。探索我们对 OpenTelemetry Demo 的公开部署，并了解 Elastic 的解决方案如何增强你的可观察性体验。

最近，Elastic 为各种 OpenTelemetry 组件引入了 Elastic Distributions (EDOT)，我们很自豪地宣布，这些 EDOT 组件现已在 Elastic 的 OpenTelemetry Demo 分支中可用。我们还公开了一个 Kibana 端点，让你可以深入了解演示的实时数据并亲自探索其功能。在这篇博文中，我们将详细说明分支背后的原因，并探索它引入的强大新功能。我们还将全面概述如何利用这些增强功能与 OpenTelemetry (EDOT) 的 Elastic Distributions 进行高级错误检测，以及 EDOT Collector（Elastic Agent 的尖端发展）进行无缝数据收集和分析。

什么是 OpenTelemetry 演示？

OpenTelemetry 演示是一个基于微服务的应用程序，由 OpenTelemetry 社区创建，旨在展示其在现实的分布式系统环境中的功能。这个演示应用程序称为 OpenTelemetry Astronomy Shop，它模拟了一个由 10 多个互连微服务（以多种语言编写：Go、Java、.NET、Node.js 等）组成的电子商务网站，通过 HTTP 和 gRPC 进行通信。每项服务都完全使用 OpenTelemetry 进行检测，生成全面的跟踪、指标和日志。该演示是了解如何在实际应用程序中实现和使用 OpenTelemetry 的宝贵资源。

其中一项微服务名为 loadgenerator，它会自动开始向演示的各个端点生成请求，模拟多个客户端与系统交互的真实环境。这有助于复制具有并发用户活动的繁忙实时应用程序的行为。

Elastic 的分支

Elastic 认识到了通过分支 OpenTelemetry Demo 并集成高级 Elastic 功能来增强 OpenTelemetry Demo 的机会，以实现更深入的可观察性和更简单的监控。虽然分支是推荐的 OpenTelemetry 方法，但我们的目标是尽可能利用上游版本的强大基础和最新更新。为了实现这一点，Elastic 的 OpenTelemetry Demo 分支每天都会从上游进行拉取，将它们与 Elastic 特定的更改无缝集成。为了避免冲突，我们不断向上游做出贡献，确保 Elastic 的修改始终是附加的或可通过环境变量进行配置的。其中一个贡献是 .env.override 文件，它专为供应商分支而设计，用于覆盖演示中使用的微服务镜像和配置文件。

使用 Elastic 发行版获得更深入的洞察

在 Elastic 的 OpenTelemetry Demo 分支的最新更新中，我们已将用于检测的一些微服务 OTel SDK 替换为 Elastic 的专用发行版。这些更改确保与 Elastic 的可观察性工具进行更深入的集成，提供更丰富的洞察和更强大的监控功能。以下是分支的一些更改：

Java 服务：广告、欺诈检测和 Kafka 服务现在使用 OpenTelemetry Java 代理的 Elastic 发行版。发行版中包含的功能之一是堆栈跟踪，它提供有关 span 起源于代码路径中何处的精确信息。在此处了解有关 Elastic Java 代理的更多信息。

Cart 服务已升级为使用 OpenTelemetry .NET 代理的 Elastic 发行版。此替换可让你了解如何使用 OpenTelemetry .NET 的 Elastic 发行版 (EDOT .NET) 开始在 .NET 应用程序中使用 OpenTelemetry，而无需进行任何代码更改。在此博客文章中了解有关 Elastic .NET 代理的更多信息。

在 Payment 服务中，我们配置了 OpenTelemetry Node.js 代理的 Elastic 发行版。该发行版附带 host-metrics 扩展，Kibana 提供了精选的服务指标 UI。在此处阅读有关 Elastic Node.js 代理的更多信息。

Recommendation 服务现在利用 EDOT Python，取代了标准的 OpenTelemetry Python 代理。Python 发行版是零代码（或自动）检测的另一个示例，这意味着发行版将设置 OpenTelemetry SDK 并为你启用所有推荐的检测。在此博客文章中了解有关 Elastic Python Agent 的更多信息。

需要强调的是，OpenTelemetry 的 Elastic 发行版不捆绑专有软件，它们建立在原始 OTel SDK 之上，但它们提供了一些优势，例如安装的单一软件包、使用合理的默认配置轻松自动检测、自动日志遥测发送等等。沿着这些思路，最终目标是将尽可能多的 EDOT 功能贡献给上游 OpenTelemetry 代理；它们的设计方式是，作为扩展实现的附加功能可直接与 OTel SDK 配合使用。

使用 Elastic Collector Distribution 收集数据

OpenTelemetry Demo 应用程序生成信号并将其发送到 OpenTelemetry Collector OTLP 端点。在 Demo 的分支中，EDOT 收集器设置为将所有 OTLP 信号从微服务转发到 APM 服务器 OTLP 端点。此外，它还将收集器收集的所有其他指标和日志发送到 Elasticsearch 端点。

如果分支部署在 Kubernetes 环境中，收集器将自动开始收集系统的指标。收集器将配置为使用 hostmetrics 接收器来监控所有 K8s 节点的指标，使用 kuebeletstats 接收器来检索 Kubelet 的指标，使用 filelog 接收器来收集所有集群的指标。

微服务生成的信号和 EDOT 收集器收集的信号都富含 Kubernetes 元数据，使用户可以无缝关联它们。这样可以轻松跟踪和观察每个服务在哪些 Kubernetes 节点和 pod 上运行，从而深入了解应用程序性能和基础设施健康状况。

了解有关 Elastic 的 OpenTelemetry Collector 发行版的更多信息：https://www.elastic.co/observability-labs/blog/elastic-distribution-opentelemetry-collector

使用 Elastic 进行错误检测

OpenTelemetry Demo 结合了 flagd，这是一个用于模拟错误场景的功能标志评估引擎。例如，paymentServiceFailure 标志将强制对 charge 服务收费端点的每个请求都产生错误。由于该服务使用 OpenTelemetry 进行检测，因此错误将被捕获到生成的跟踪中。然后，我们可以使用 Kibana 强大的可视化和搜索工具将错误追溯到其根本原因。

另一个可用标志名为 adServiceHighCpu，它会导致广告服务中的 CPU 负载过高。可以通过服务的指标或其 Kubernetes pod 的相关指标来监控这种增加的 CPU 使用率：

模拟场景的完整列表可在此链接中找到。

开始你自己的探索

准备好探索带有 Elastic 的 OpenTelemetry Demo 及其增强的可观察性功能了吗？点击 Kibana 链接，开始你自己的探索，了解 Elastic 和 OpenTelemetry 如何改变你的可观察性方法。

现场演示：https://ela.st/demo-otel

但这还不是全部 —— 如果你想更进一步，你可以直接使用自己的 Elasticsearch 堆栈部署 OpenTelemetry Demo。按照此处提供的步骤进行设置，并开始从你自己的环境中获得有价值的见解。

原文：OpenTelemetry Demo with the Elastic Distributions of OpenTelemetry — Elastic Observability Labs