Observability：使用 Elastic AI Assistant 和 APM 分析 OpenTelemetry 应用程序

标签：Elastic AI Assistant OpenTelemetry SLO APM

作者：来自 Elastic Bahubali Shetti

OpenTelemetry 正在迅速成为云原生计算基金会 (CNCF) 内最广泛的项目，拥有与 Kubernetes 一样多的提交，并获得了客户的广泛支持。许多公司正在采用 OpenTelemetry 并将其集成到他们的应用程序中。 Elastic® 提供了有关为应用程序实施 OpenTelemetry 的详细指南。然而，与许多应用程序一样，查明和解决问题可能非常耗时。

Elastic AI Assistant 不仅在识别问题方面，而且在解决问题方面都显着增强了流程。 Elastic 的新服务级别目标 (service leverl objective - SLO) 功能进一步增强了这一点，使你能够简化从检测潜在问题到增强整体客户体验的整个站点可靠性工程 (SRE) 流程。

在本博客中，我们将演示你作为 SRE 如何检测配备 OpenTelemetry 的服务中的问题。我们将探索使用 Elastic APM、Elastic 的 AIOps 功能和 Elastic AI Assistant 来识别问题。

我们将使用 OpenTelemetry 演示来说明这一点，并激活一个功能标志 (cartService)。

我们的演练将包含两种场景：

当购物车服务的 SLO 不合规时，我们将通过 Elastic APM 分析错误。 Elastic AI Assistant 将通过提供运行手册和 GitHub 问题来协助问题分析。
如果购物车服务的 SLO 不合规，我们将检查指示高故障率的跟踪。我们将使用 AIOps 进行故障关联，并使用 AI Assistant 直接从 Assistant 分析日志和 Kubernetes 指标。

先决条件和配置

如果你计划关注此博客，以下是我们用于设置配置的一些组件和详细信息：

确保你在 Elastic Cloud上有一个帐户并已部署堆栈（请参阅此处的说明）。
我们使用了 OpenTelemetry 演示。有关将 Elastic 与 OpenTelemetry 演示结合使用的说明，请参见此处。
此外，你还需要将你的人工智能助手连接到你最喜欢的 LLM。我们使用 Azure OpenAI GPT-4。
我们还在 Kubernetes（特别是 GKE）上运行了 OpenTelemetry 演示。

SLO 不合规

Elastic APM 最近在 8.12 中发布了 SLO（服务级别目标）功能。此功能允许为服务设置可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度，或者定义你自己的目标。关键组件包括：

定义和监控 SLI（service level indicators - 服务水平指标）
监控错误预算以表明允许的性能缺陷
基于错误预算消耗情况进行告警

我们为购物车服务设置了两个 SLO：

可用性 SLO，通过确保事务成功来监控其可用性。我们在 OpenTelemetry 应用程序中设置了功能标志，该标志在 10% 的情况下会为 EmptyCart 交易生成错误。
延迟 SLO，确保 transaction 不会低于特定延迟，否则会降低客户体验。

由于 OTel cartservice 功能标记，可用性 SLO 被触发，并且在 SLO 详细信息中，我们看到在 7 天的时间内可用性远低于我们的目标 99.9（95.5）。此外，所有可用的错误预算也已耗尽。

借助 SLO，你可以轻松识别何时会出现客户体验问题，或者何时会出现潜在的服务问题，以免问题变得更糟。

场景一：使用AI助手分析APM轨迹和日志

一旦发现 SLO 不合规，我们就可以深入到购物车服务中，在 Elastic APM 中进行调查。下面介绍了你可以在 Elastic APM 中执行的一系列步骤以及如何使用 AI Assistant 来分析问题：

OTEL AI - Elastic 可观则

从视频中我们可以看到，一旦进入 APM，我们就采取了以下步骤。

调查了 EmptyCart 踪迹，发现其故障率高于正常水平。
跟踪显示大量故障，这也导致延迟稍长。
我们使用 AIOps 故障关联来识别导致故障的潜在组件，该组件与 FailedPrecondition 的字段值相关。
在过滤该值并查看日志时，我们仍然无法理解这意味着什么。
你可以在此处使用 Elastic 的 AI Assistant 来进一步了解该问题。

AI 助手帮助我们分析了以下内容：

它帮助我们理解日志消息的含义以及它与 Redis 连接失败问题相关。
由于我们无法连接到 Redis，我们要求 AI Assistant 为我们提供 Redis Kubernetes Pod 的指标。
我们从过去两个小时的日志中了解到 Redis 有两个 pod。
然而，我们也了解到，一个人的记忆力似乎在增加。
Redis 似乎已重新启动（因此出现了第二个 Pod），通过这些信息，我们可以更深入地了解 Redis 发生了什么。

你可以看到我们通过 AI Assistant 和 Elastic 的 APM 功能关联大量信息、日志、指标和跟踪的速度有多快。我们不必通过多个屏幕来寻找信息。

场景2：使用 AI 助手分析 APM 错误

一旦发现 SLO 不合规，我们就可以深入到购物车服务中，在 Elastic APM 中进行调查。以下逐步介绍了你可以在 Elastic APM 中执行并使用 AI Assistant 来分析问题的一组步骤：

可观察性 AI 助手-8.12

从视频中我们可以看到，进入APM后，我们采取了以下步骤：

我们注意到 APM 服务存在一个特定错误。
我们在错误选项卡中对此进行了调查，虽然我们发现这是与 Redis 连接的问题，但我们仍然需要更多信息。
AI Assistant 帮助我们理解堆栈跟踪，并提供一些潜在的错误原因以及诊断和解决它的方法。
我们还要求其提供由我们的 SRE 团队创建的操作手册，其中为我们提供了解决此特定问题的步骤。

但正如你所看到的，AI Assistant 不仅为我们提供了有关错误消息的信息，还为我们提供了如何诊断它并可能通过内部运行手册解决它。

实现卓越运营、最佳性能和可靠性

我们展示了如何使用 Elastic 的功能（尤其是与 Elastic APM、AIOps 和最新的 SLO 功能相结合的 AI Assistant）来分析 OpenTelemetry 仪表化应用程序（OTel 演示）。 Elastic 显着简化了识别和解决应用程序中问题的过程。

通过对两个不同场景的详细演练，我们了解了 Elastic APM 和 AI Assistant 如何有效分析和解决购物车服务中不符合 SLO 的问题。通过这些工具快速关联信息、日志、指标和跟踪的能力不仅可以节省时间，还可以提高故障排除过程的整体效率。

在这些场景中使用 Elastic 的 AI Assistant 凸显了将高级 AI 功能集成到操作工作流程中的价值。它超越了简单的错误分析，提供了对潜在原因的洞察并提供了可行的解决方案，有时甚至提供了定制的运行手册。这种技术集成从根本上改变了 SRE 解决问题的方式，使流程更加高效，减少对人工调查的依赖。

总体而言，Elastic 的 APM、AIOps 功能和 AI Assistant 的进步，特别是在处理 OpenTelemetry 数据方面，代表了卓越运营方面的重大进步。这些工具使 SRE 不仅能够对新出现的问题做出快速反应，还能主动管理和优化其服务的性能和可靠性，从而确保增强的客户体验。

原文：Analyzing OpenTelemetry Apps with Elastic AI Assistant and APM | Elastic Blog

标签：Elastic,AI,Assistant,OpenTelemetry,SLO,APM
From： https://blog.csdn.net/UbuntuTouch/article/details/136682008