使用 ES|QL 优化可观察性：简化 Kubernetes 和 OTel 的 SRE 操作和问题解决

作者：Bahubali Shetti

作为一名运营工程师（SRE、IT 运营、DevOps），管理技术和数据蔓延是一项持续的挑战。简单地管理大量高维和高基数数据是令人难以承受的。

作为单一平台，Elastic® 帮助 SRE 将无限的遥测数据（包括指标、日志、跟踪和分析）统一并关联到单一数据存储 — Elasticsearch® 中。然后，通过应用 Elastic 的高级机器学习 (ML)、AIOps、AI Assistant 和分析的强大功能，你可以打破孤岛并将数据转化为见解。作为全栈可观测性解决方案，从基础设施监控到日志监控和应用程序性能监控 (APM) 的所有内容都可以在单一、统一的体验中找到。

在 Elastic 8.11 中，Elastic 的新管道查询语言 ES|QL（Elasticsearch 查询语言）现已提供技术预览，它可以转换、丰富和简化数据调查。在新的查询引擎的支持下，ES|QL 提供了具有并发处理的高级搜索功能，从而提高了速度和效率，而不受数据源和结构的影响。通过从一个屏幕创建聚合和可视化来加速解决问题，提供迭代、不间断的工作流程。

ES|QL 对于 SRE 的优势

使用 Elastic Observability 的 SRE 可以利用 ES|QL 来分析日志、指标、跟踪和分析数据，使他们能够通过单个查询查明性能瓶颈和系统问题。在 Elastic Observability 中使用 ES|QL 管理高维和高基数数据时，SRE 具有以下优势：

提高运营效率：通过使用 ES|QL，SRE 可以使用聚合值作为单个查询的阈值来创建更多可操作的通知，这些通知也可以通过 Elastic API 进行管理并集成到 DevOps 流程中。
通过洞察增强分析：ES|QL 可以处理各种可观测数据，包括应用程序、基础设施、业务数据等，无论来源和结构如何。 ES|QL 可以轻松地通过附加字段和上下文丰富数据，从而允许通过单个查询创建仪表板可视化或问题分析。
缩短解决问题的平均时间：ES|QL 与 Elastic Observability 的 AIOps 和 AI Assistant 结合使用，可通过识别趋势、隔离事件和减少误报来提高检测准确性。这种上下文的改进有助于故障排除以及快速查明和解决问题。

Elastic Observability 中的 ES|QL 不仅增强了 SRE 更有效地管理客户体验、组织收入和 SLO 的能力，而且还通过提供上下文聚合数据来促进与开发人员和 DevOps 的协作。

在本博客中，我们将介绍 SRE 可以利用 ES|QL 的一些关键用例：

ES|QL 与 Elastic AI Assistant 集成，使用公共 LLM 和私有数据，增强了 Elastic Observability 中任何地方的分析体验。
SRE 可以在单个 ES|QL 查询中分解、分析和可视化来自多个来源和跨任何时间范围的可观察性数据。
可以通过单个 ES|QL 查询轻松创建可操作的警报，从而增强操作。

我将通过展示 SRE 如何解决使用 OpenTelemetry 检测并在 Kubernetes 上运行的应用程序中的问题来完成这些用例。 OpenTelemetry (OTel) 演示位于 Amazon EKS 集群上，并配置了 Elastic Cloud 8.11。

你还可以查看我们的 Elastic Observability ES|QL 演示，该演示演示了可观察性的 ES|QL 功能。

ES|QL 与 AI 助手

作为 SRE，你正在使用 Elastic Observability 监控 OTel 仪表化应用程序，而在 Elastic APM 中，你会注意到 service map 中突出显示的一些问题。

使用 Elastic AI Assistant，你可以轻松要求进行分析，特别是，我们会检查应用程序服务的总体延迟情况。

My APM data is in traces-apm*. What's the average latency per service over the last hour? Use ESQL, the data is mapped to ECS

Elastic AI Assistant 生成一个 ES|QL 查询，我们在 AI Assistant 中运行该查询以获取所有应用程序服务的平均延迟列表。我们可以很容易地看到前四名是：

load generator
front-end proxy
frontendservice
checkoutservice

通过 AI Assistant 中的简单自然语言查询，它生成了单个 ES|QL 查询，帮助列出跨服务的延迟。

注意到多个服务存在问题，我们决定从前端代理（front-end proxy）开始。当我们研究细节时，我们看到了重大故障，并且通过 Elastic APM 故障关联，很明显前端代理没有正确完成对下游服务的调用。

Discover 中的 ES|QL 洞察力和上下文分析

了解应用程序在 Kubernetes 上运行后，我们会调查 Kubernetes 中是否存在问题。我们特别想查看是否有任何服务存在问题。

我们在 Elastic Discover 的 ES|QL 中使用以下查询：

from metrics-* | where kubernetes.container.status.last_terminated_reason != "" and kubernetes.namespace == "default" | stats reason_count=count(kubernetes.container.status.last_terminated_reason) by kubernetes.container.name, kubernetes.container.status.last_terminated_reason | where reason_count > 0

ES|QL 帮助分析来自 Kubernetes 的 1,000 个/10,000 个指标事件，并突出显示由于 OOMKilled 而重新启动的两个服务。

当被问及 OOMKilled 时，Elastic AI Assistant 表示 pod 中的容器由于内存不足而被终止。

我们运行另一个 ES|QL 查询来了解电子邮件服务和产品目录服务的内存使用情况。

ES|QL 很容易发现平均内存使用量相当高。

我们现在可以进一步调查这两个服务的日志、指标和 Kubernetes 相关数据。然而，在继续之前，我们创建一个警报来跟踪大量内存使用情况。

使用 ES|QL 发出可操作的警报

怀疑可能会再次出现的特定问题，我们只需创建一个警报，引入我们刚刚运行的 ES|QL 查询，该查询将跟踪内存利用率超过 50% 的任何服务。

我们修改最后一个查询以查找内存使用率高的任何服务：

FROM metrics*
| WHERE @timestamp >= NOW() - 1 hours
| STATS avg_memory_usage = AVG(kubernetes.pod.memory.usage.limit.pct) BY kubernetes.deployment.name | where avg_memory_usage > .5

通过该查询，我们创建一个简单的警报。请注意如何将 ES|QL 查询引入警报中。我们简单地将其与寻呼机职责联系起来。但我们可以从多个连接器中进行选择，例如 ServiceNow、Opsgenie、电子邮件等。

通过此警报，我们现在可以轻松监控 pod 中内存利用率超过 50% 的任何服务。

使用 ES|QL 充分利用你的数据

在这篇文章中，我们展示了 ES|QL 为分析、操作和减少 MTTR 带来的强大功能。综上所述，Elastic Observability 中 ES|QL 的三个用例如下：

ES|QL 与 Elastic AI Assistant 集成，使用公共 LLM 和私有数据，增强了 Elastic Observability 中任何地方的分析体验。
SRE 可以在单个 ES|QL 查询中分解、分析和可视化来自多个来源和跨任何时间范围的可观察性数据。
可以通过单个 ES|QL 查询轻松创建可操作的警报，从而增强操作。

Elastic 邀请 SRE 和开发人员亲身体验这种变革性语言，并开启数据任务的新视野。今天就在 https://ela.st/free-Trial上尝试一下，现在处于技术预览版。