Bahubali Shetti

使用 Elastic AI 助手和 APM 分析 OpenTelemetry 应用

Elastic Observability 提供原生的 OpenTelemetry 支持,但分析应用程序的日志、指标和追踪可能令人生畏。Elastic Observability 不仅提供 AIOps 功能,还提供 AI 助手(副驾驶)来帮助更快地实现 MTTR。

Analyzing OpenTelemetry apps with Elastic AI Assistant and APM

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

Elastic AI 助手不仅在识别而且在解决问题方面都显著增强了该过程。Elastic 的新服务级别目标 (SLO) 功能进一步增强了这一功能,使您能够简化整个站点可靠性工程 (SRE) 流程,从检测潜在问题到提升整体客户体验。

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

我们将使用OpenTelemetry 演示进行说明,其中激活了功能标志 (cartService)

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

  1. 当购物车服务的 SLO 不合规时,我们将通过 Elastic APM 分析错误。Elastic AI 助手将通过提供运行手册和 GitHub 问题来协助问题分析。

  2. 如果购物车服务的 SLO 不合规,我们将检查表明失败率高的追踪。我们将使用 AIOps 进行故障关联,并使用 AI 助手直接从助手分析日志和 Kubernetes 指标。

先决条件和配置

如果您计划阅读本博客,以下是我们在设置配置时使用的一些组件和详细信息

  • 确保您在 Elastic Cloud 上拥有帐户,并且已部署堆栈(请参阅此处的说明)。

  • 我们使用了 OpenTelemetry 演示。有关将 Elastic 与 OpenTelemetry 演示结合使用的说明此处

  • 此外,您还需要将您的 AI 助手连接到您最喜欢的 LLM。我们使用了 Azure OpenAI GPT-4。

  • 我们还在 Kubernetes 上,特别是在 GKE 上运行了 OpenTelemetry 演示。

SLO 不合规

Elastic APM 最近在 8.12 中发布了 SLO(服务级别目标)功能。此功能可为服务设置可衡量的性能目标,例如可用性、延迟、流量、错误和饱和度或定义您自己的。主要组件包括

  • 定义和监控 SLI(服务级别指标)

  • 监控错误预算,指示允许的性能不足

  • 当显示错误预算消耗情况时发出警报

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

  • 可用性 SLO,它通过确保事务成功来监控其可用性。我们在 OpenTelemetry 应用程序中设置了功能标志,该标志在 10% 的时间内为 EmptyCart 事务生成错误。

  • 延迟 SLO 确保事务不低于特定延迟,这将减少客户体验。

由于 OTel 购物车服务功能标志,触发了可用性 SLO,并且在 SLO 详细信息中,我们看到在七天的时间内,可用性远低于我们 99.9 的目标,达到 95.5。此外,所有可用的错误预算也已耗尽。

通过 SLO,您可以轻松识别何时出现客户体验问题,或者何时在潜在问题变得更糟之前出现服务潜在问题。

场景 1:使用 AI 助手分析 APM 追踪和日志

一旦发现 SLO 不合规,我们就可以深入研究购物车服务,以在 Elastic APM 中进行调查。以下内容介绍了您可以在 Elastic APM 中采取的一系列步骤,以及如何使用 AI 助手分析问题

Video Thumbnail

从视频中我们可以看到,进入 APM 后,我们执行了以下步骤。

  1. 调查了经历异常高失败率的 EmptyCart 追踪。

  2. 该追踪显示了大量失败,这也导致了略微更大的延迟。

  3. 我们使用 AIOps 故障关联来识别导致故障的潜在组件,该组件与 FailedPrecondition 的字段值相关联。

  4. 在筛选该值并查看日志时,我们仍然不明白这意味着什么。

  5. 您可以在这里使用 Elastic 的 AI 助手,以进一步了解问题。

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

  1. 它帮助我们理解了日志消息的含义,以及它与 Redis 连接失败问题相关。

  2. 由于我们无法连接到 Redis,我们要求 AI 助手提供 Redis Kubernetes Pod 的指标。

  3. 我们从过去两个小时的日志中了解到,Redis 有两个 Pod。

  4. 然而,我们也了解到其中一个 Pod 的内存似乎在增加。

  5. 似乎 Redis 重新启动了(因此有了第二个 Pod),有了这些信息,我们可以深入研究 Redis 发生了什么。

您可以看到我们如何通过 AI 助手和 Elastic 的 APM 功能快速关联大量信息、日志、指标和跟踪。我们不必浏览多个屏幕来查找信息。

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

一旦发现 SLO 不合规,我们就可以深入到购物车服务中,在 Elastic APM 中进行调查。以下步骤将引导您了解在 Elastic APM 中可以采取的步骤,并使用 AI 助手来分析问题

Video Thumbnail

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

  1. 我们注意到 APM 服务的特定错误。

  2. 我们在错误选项卡中对此进行了调查,虽然我们看到这是与 Redis 连接的问题,但我们仍然需要更多信息。

  3. AI 助手帮助我们理解了堆栈跟踪,并提供了一些导致错误的潜在原因,以及诊断和解决问题的方法。

  4. 我们还要求它提供由我们的 SRE 团队创建的运行手册,该手册提供了解决此特定问题的步骤。

但正如您所见,AI 助手不仅为我们提供了有关错误消息的信息,还提供了如何诊断和潜在地使用内部运行手册解决问题的方法。

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

我们已经展示了如何使用 Elastic 的功能分析 OpenTelemetry 仪表化的应用程序(OTel 演示),特别是与 Elastic APM、AIOps 和最新的 SLO 功能相结合的 AI 助手。Elastic 显著简化了识别和解决应用程序中问题的过程。

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

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

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

立即试用

现有的 Elastic Cloud 客户可以直接从 Elastic Cloud 控制台访问许多这些功能。尚未利用云上的 Elastic?开始免费试用

本文中描述的任何功能或功能的发布和时间安排均由 Elastic 自行决定。任何目前不可用的功能或功能可能不会按时交付或根本不交付。

在此博客文章中,我们可能使用了或提及了第三方生成式 AI 工具,这些工具由其各自的所有者拥有和运营。Elastic 对第三方工具没有任何控制权,我们对其内容、操作或使用,以及因您使用此类工具而可能引起的任何损失或损害不承担任何责任。在使用带有个人、敏感或机密信息的 AI 工具时,请务必谨慎。您提交的任何数据都可能被用于 AI 训练或其他目的。我们不保证您提供的信息将保持安全或机密。您应在使用任何生成式 AI 工具之前熟悉其隐私惯例和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 在美国和其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

分享这篇文章