作为一名运维工程师（SRE、IT 运维、DevOps），管理技术和数据激增是一个持续的挑战。仅仅管理海量高维度、高基数的数据就已不堪重负。
Elastic® 作为单一平台，帮助 SRE 将无限的遥测数据（包括指标、日志、跟踪和分析）统一关联到单个数据存储中——Elasticsearch®。然后，通过应用 Elastic 的高级机器学习 (ML)、AIOps、AI 助手和分析功能，您可以打破数据孤岛，将数据转化为洞察力。作为全栈可观测性解决方案，从基础设施监控到日志监控和应用程序性能监控 (APM)，所有功能都可以在单个统一的体验中找到。
在 Elastic 8.11 中，现在可以技术预览Elastic 的新型管道查询语言 ES|QL（Elasticsearch 查询语言），它可以转换、丰富和简化数据调查。ES|QL 由一个新的查询引擎提供支持，它提供了具有并发处理功能的高级搜索功能，提高了速度和效率，而不管数据源和结构如何。通过在一个屏幕上创建聚合和可视化来加速解决方案，提供迭代的、不间断的工作流程。
ES|QL 对 SRE 的优势
使用 Elastic 可观测性的 SRE 可以利用 ES|QL 来分析日志、指标、跟踪和分析数据，从而使他们能够通过单个查询来精确定位性能瓶颈和系统问题。在 Elastic 可观测性中使用 ES|QL 管理高维度和高基数数据时，SRE 可以获得以下优势：
- 提高运营效率：通过使用 ES|QL，SRE 可以使用单个查询中聚合值作为阈值来创建更多可操作的通知，这些通知也可以通过 Elastic API 进行管理并集成到 DevOps 流程中。
- 增强分析和洞察力：ES|QL 可以处理各种可观测性数据，包括应用程序、基础设施、业务数据等等，而不管其来源和结构如何。ES|QL 可以轻松地用其他字段和上下文丰富数据，从而允许使用单个查询创建仪表板可视化或问题分析。
- 缩短平均故障恢复时间：ES|QL 与 Elastic 可观测性的 AIOps 和 AI 助手相结合，通过识别趋势、隔离事件和减少误报来提高检测精度。上下文信息的改进有助于故障排除以及快速查明和解决问题。
ES|QL 在 Elastic 可观测性中不仅增强了 SRE 更有效地管理客户体验、组织收入和 SLO 的能力，而且还通过提供情境化的聚合数据来促进与开发人员和 DevOps 的协作。
在本博文中，我们将介绍 SRE 可以利用 ES|QL 的一些关键用例。
- ES|QL 与 Elastic AI 助手集成，后者使用公共 LLM 和私有数据，增强了 Elastic 可观测性中任何地方的分析体验。
- SRE 可以通过单个 ES|QL 查询，分解、分析和可视化来自多个来源和任何时间范围的可观测性数据。
- 可以轻松地从单个 ES|QL 查询创建可操作的警报，从而增强操作。
我将通过展示 SRE 如何解决在使用 OpenTelemetry 进行监控并在 Kubernetes 上运行的应用程序中的问题来逐步介绍这些用例。OpenTelemetry (OTel) 演示在一个 Amazon EKS 集群上，配置了 Elastic Cloud 8.11。
您还可以查看我们的Elastic 可观测性 ES|QL 演示，其中介绍了可观测性的 ES|QL 功能。
ES|QL 与 AI 助手
作为一名 SRE，您正在使用 Elastic 可观测性监控您的 OTel 监控应用程序，并且在 Elastic APM 中，您注意到服务地图中突出显示了一些问题。
使用 Elastic AI 助手，您可以轻松地请求分析，特别是检查整个应用程序服务的总体延迟。
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 助手生成一个 ES|QL 查询，我们在 AI 助手运行该查询以获取所有应用程序服务的平均延迟列表。我们可以轻松地看到前四个是：
- 负载生成器
- 前端代理
- 前端服务
- 结账服务
通过在AI助手里输入简单的自然语言查询，它生成了一个单一的ES|QL查询，帮助列出了各个服务间的延迟。
注意到几个服务存在问题，我们决定从前端代理开始。在详细检查过程中，我们发现严重的故障，并且通过**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中数千/万个指标事件，并突出显示了由于OOMKilled而重新启动的两个服务。
当询问OOMKilled时，Elastic AI助手指出，由于内存不足，pod中的一个容器被终止。
我们运行另一个ES|QL查询来了解emailservice和productcatalogservice的内存使用情况。
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查询是如何被引入警报的。我们只需将其连接到PagerDuty。但是我们可以选择多个连接器，例如ServiceNow、Opsgenie、电子邮件等。
有了这个警报，我们现在可以轻松监控pod中内存利用率超过50%的任何服务。
充分利用ES|QL处理您的数据
在这篇文章中，我们演示了ES|QL为分析、运维和减少MTTR带来的强大功能。总而言之，在Elastic Observability中使用ES|QL的三个用例如下：
- ES|QL 与 Elastic AI 助手集成，后者使用公共 LLM 和私有数据，增强了 Elastic 可观测性中任何地方的分析体验。
- SRE 可以通过单个 ES|QL 查询，分解、分析和可视化来自多个来源和任何时间范围的可观测性数据。
- 可以轻松地从单个 ES|QL 查询创建可操作的警报，从而增强操作。
Elastic邀请SRE和开发人员亲身体验这种变革性的语言，并在其数据任务中开辟新的视野。现在就尝试技术预览版，访问https://ela.st/free-trial。
本文中描述的任何特性或功能的发布和时间安排完全由Elastic自行决定。任何当前不可用的特性或功能可能无法按时或根本无法交付。