OpenTelemetry 正在迅速成为云原生计算基金会 (CNCF) 内最广泛的项目，其提交次数与 Kubernetes 一样多，并获得了客户的广泛支持。许多公司正在采用 OpenTelemetry 并将其集成到他们的应用程序中。Elastic® 提供了有关为应用程序实施 OpenTelemetry 的详细指南。但是，与许多应用程序一样，查明和解决问题可能非常耗时。
Elastic AI 助手 显著增强了此过程，不仅在识别问题方面，还在解决问题方面。Elastic 的新型服务级别目标 (SLO) 功能进一步增强了这一点，使您可以简化整个站点可靠性工程 (SRE) 流程，从检测潜在问题到增强整体客户体验。
在本博客中，我们将演示您作为 SRE 如何检测配备 OpenTelemetry 的服务中的问题。我们将探讨使用 Elastic APM、Elastic 的 AIOps 功能和 Elastic AI 助手进行问题识别。
我们将使用OpenTelemetry 演示来说明这一点，其中启用了特性标志 (cartService)。
我们的演练将涵盖两种场景
-
当购物车服务的 SLO 不符合要求时，我们将通过 Elastic APM 分析错误。Elastic AI 助手将通过提供运行手册和 GitHub 问题来协助进行问题分析。
-
如果购物车服务的 SLO 不符合要求，我们将检查指示高失败率的追踪。我们将使用 AIOps 进行故障关联，并使用 AI 助手直接从助手分析日志和 Kubernetes 指标。
先决条件和配置
如果您打算遵循本博客，以下列出了一些我们用来设置配置的组件和详细信息
-
确保您拥有Elastic Cloud的帐户和已部署的堆栈（请参阅此处的说明）。
-
我们使用了 OpenTelemetry Demo。使用 Elastic 和 OpenTelemetry Demo 的说明在此。
-
此外，您需要将 AI 助手连接到您喜欢的 LLM。我们使用了 Azure OpenAI GPT-4。
-
我们还在 Kubernetes（具体来说是在 GKE 上）运行 OpenTelemetry Demo。
SLO 不符合要求
Elastic APM 最近在8.12版本中发布了 SLO（服务级别目标）功能。此功能允许为服务设置可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度，或者定义您自己的目标。关键组件包括：
-
定义和监控 SLI（服务级别指标）
-
监控错误预算，指示允许的性能不足
-
根据消耗率发出警报，显示错误预算消耗情况
我们为购物车服务设置了两个 SLO：
-
**可用性 SLO**，通过确保事务成功来监控其可用性。我们在 OpenTelemetry 应用程序中设置了特性标志，该标志会以 10% 的概率为 EmptyCart 事务生成错误。
-
**延迟 SLO**，以确保事务不会低于特定延迟，这将降低客户体验。
由于 OTel cartservice 特性标志，可用性 SLO 被触发，并且在 SLO 详细信息中，我们看到在七天的时间内，可用性远低于我们的 99.9 的目标，仅为 95.5。此外，所有可用的错误预算也已用尽。
使用 SLO，您可以轻松识别客户体验问题何时发生，或者服务潜在问题何时出现，从而防止问题变得更糟。
方案 1：使用 AI 助手分析 APM 追踪和日志
一旦发现 SLO 不符合要求，我们就可以深入研究购物车服务以在 Elastic APM 中进行调查。以下介绍了您可以在 Elastic APM 中执行的一系列步骤以及如何使用 AI 助手来分析问题。
从视频中，我们可以看到，一旦进入 APM，我们执行了以下步骤。
-
调查了 EmptyCart 追踪，该追踪的失败率高于正常水平。
-
追踪显示大量失败，这也导致延迟略微增加。
-
我们使用 AIOps 故障关联来识别可能导致故障的组件，该组件与“FailedPrecondition”的字段值相关。
-
在过滤该值并查看日志时，我们仍然无法理解这意味着什么。
-
这时您可以使用 Elastic 的 AI 助手来进一步了解问题。
AI 助手帮助我们分析了以下内容：
-
它帮助我们理解了日志消息的含义，以及它与 Redis 连接失败问题相关。
-
由于无法连接到 Redis，我们请求 AI 助手为 Redis Kubernetes Pod 提供指标。
-
我们在过去两小时的日志中了解到有两个 Redis Pod。
-
但是，我们还了解到其中一个 Pod 的内存似乎在不断增加。
-
看起来 Redis 重启了（因此出现了第二个 Pod），有了这些信息，我们可以更深入地了解 Redis 发生了什么。
您可以看到，通过 AI 助手和 Elastic 的 APM 功能，我们可以多快地关联大量信息、日志、指标和追踪。我们无需在多个屏幕之间来回查找信息。
场景 2：使用 AI 助手分析 APM 错误
一旦发现 SLO 不符合要求，我们就可以深入研究购物车服务以在 Elastic APM 中进行调查。以下是您可以在 Elastic APM 中采取的步骤，并使用 AI 助手来分析问题。
从视频中，我们可以看到，一旦进入 APM，我们采取了以下步骤：
-
我们注意到 APM 服务存在特定错误。
-
我们在错误选项卡中对此进行了调查，虽然我们看到这是与 Redis 连接的问题，但我们仍然需要更多信息。
-
AI 助手帮助我们理解堆栈跟踪，并提供一些潜在的错误原因以及诊断和解决方法。
-
我们还请求了由我们的 SRE 团队创建的操作手册，该手册为我们提供了解决此特定问题的步骤。
但正如您所看到的，AI 助手不仅提供有关错误消息的信息，还提供如何诊断错误以及如何使用内部操作手册来解决错误的方案。
实现卓越运营、最佳性能和可靠性
我们展示了如何使用 Elastic 的功能（特别是 AI 助手与 Elastic APM、AIOps 和最新的 SLO 功能相结合）来分析使用 OpenTelemetry 进行检测的应用程序 (OTel 演示)。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. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称是其各自所有者的商标、徽标或注册商标。