Elastic Observability 8.11：ES|QL、APM 中的通用分析和增强的 SLOs

本文主要是介绍Elastic Observability 8.11：ES|QL、APM 中的通用分析和增强的 SLOs，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：Tom Grabowski, Katrin Freihofner, Israel Ogbole

Elastic Observability 8.11 引入了 ES|QL for Observability（技术预览版）、Universal ProfilingTM 和 Elastic APM 集成，以及针对 Elastic Observability 的新 SLO （Service Level Objective）增强功能：

ES|QL for Elastic Observability：Elasticsearch 查询语言 (ES|QL) 现在处于技术预览版，它可以转换、丰富和简化数据调查。了解 ES|QL 如何与 Elastic AI Assistant 集成、轻松创建警报以及通过单个查询创建上下文洞察。
使用 Elastic APM 进行通用分析：将应用程序性能问题与 APM 中的底层系统功能相关联，而无需切换上下文。这有助于 SRE 提高可见性并缩短解决问题的时间。
SLO 技术预览版中添加的新功能增强了操作体验，其中包括添加仪表板作为面板、新的错误率图表、按 APM 指标进行分区的功能等等。

Elastic Observability 8.11 现已在 Elastic Cloud 上推出，这是唯一包含最新版本中所有新功能的托管 Elasticsearch® 产品。你还可以下载 Elastic Stack 和我们的云编排产品 Elastic Cloud Enterprise 和 Elastic Cloud for Kubernetes，以获得自我管理的体验。

Elastic 8.11 中还有哪些新功能？查看8.11公告帖子了解更多>>

ES|QL 用于可观察性

AI助手 ES|QL 增强

Elastic AI Assistant for Observability 现在包含 ES|QL 功能，允许用户使用自然语言来解释查询，并让 AI 助手提供 ES|QL 查询语法，解释查询的作用，并提供提示运行请求的查询。

ES|QL 可观测性警报

新的 ES|QL 警报规则类型已无缝集成到 Elasticsearch 规则中，现在可在 Observability 中使用。此规则类型通过强大的 ES|QL 语言提供新的高级功能，支持复杂的警报场景和用例。此外，用户还可以在最终确定和保存规则之前预览和分析 ES|QL 查询的结果。如果查询返回空结果，则不会生成任何警报。

在下面的示例中，我们使用 ES|QL 查询来查找原始、未解析的 Nginx 日志中的域。我们对错误率高于 10% 的领域感兴趣。此查询帮助我们识别有问题的域。我们将此查询合并到我们的 ES|QL 警报规则中，以便在发生此类问题时通知我们。

ES|QL 查询：

from high-cardinality-data-fake_stack.nginx_proxy-* | grok message "%{DATA:log_date} %{IP:client_ip} - %{DATA:user} admin-console.%{DATA:domain} to: %{DATA:host.name}:%{DATA:http_port}: \"%{DATA:request_method} %{DATA:request_path} %{DATA:http_version}\" %{NUMBER:status_code} %{NUMBER:bytes} \"%{DATA:url}\" \"%{GREEDYDATA:user_agent}\"" | eval good = to_double(to_long(status_code) < 500), bad = to_double(to_long(status_code) >= 500) | stats total_bad = sum(bad), total_good = sum(good) by domain| eval error_rate = (total_bad / (total_bad + total_good)) | WHERE error_rate > 0.1 | drop total_bad, total_good

更好地结合在一起：通用分析 (Universal Profiling) 和 APM 集成

我们很高兴地宣布，我们增加了用户快速将应用程序性能问题与底层系统功能关联起来的功能，而无需将上下文从 APM 切换到通用分析。

这种集成提供了许多好处，包括：

缩短解决时间：DevOps 和 SRE 现在可以排除故障并查明生产代码中的性能和错误，具体到代码的特定部分以及需要修改和/或升级的第三方库等。这一切都在 APM 服务视图中完成，无需切换上下文。
改进的可见性：通用分析为主机上运行的所有应用程序的运行时行为提供了前所未有的代码可见性。它分析运行你的服务的主机上的每一行代码，不仅包括你的应用程序代码，还包括内核和第三方库。这可以帮助你识别同一主机上可能影响特定服务性能的次优库和其他进程或服务。

observability-8-11-opbeans-java

假设你正在主机上运行容器化 Java 服务。使用 APM，你会注意到 Java 服务的性能随着时间的推移而下降。在 APM 服务页面中，通用分析用于识别消耗最多 CPU 时间的特定函数调用。你发现花费最多时间的函数之一是调用用于连接到 Redis 的库。

你进一步调查发现该库很旧，并且没有使用最有效的方式连接到 Redis。你对库进行了必要的更改，Java 服务的性能就会显着提高。

除了识别次优库之外，通用分析还可用于检测同一主机上可能影响特定服务性能的其他进程或服务。例如，你可能有一个与相关服务无关的进程，该进程正在使用大量 CPU 资源，这可能会对你的服务产生连锁反应。

通过将通用分析与 APM 集成，DevOps 和 SRE 可以更深入地了解其代码的运行时行为，并更快、更高效地识别性能瓶颈并进行故障排除。