Observerbility：使用 Elastic 中的 GenAI 进行 NGINX 日志分析

作者：来自 Elastic Bahubali Shetti

Elastic 拥有一系列嵌入式功能，例如基于 GenAI RAG 的 AI 助手和机器学习平台，这些功能是产品基线的一部分。这些功能让你可以更轻松地分析从 NGINX 获得的大量日志。

Elastic Observability 提供完整的可观察性解决方案，支持应用程序和基础设施的指标、跟踪和日志。NGINX 广泛应用于 Web 服务、负载平衡、http 缓存和反向代理，是许多应用程序的关键，并输出大量日志。NGINX 的访问日志详细记录了对 NGINX 服务器的所有请求，错误日志记录了与服务器相关的问题和故障，是管理和分析 NGINX 问题以及了解应用程序发生的情况的关键。

在管理 NGINX 时，Elastic 提供了多种功能：

1. 轻松提取、解析和开箱即用的仪表板。查看我们文档中的简单操作方法。基于日志，这些仪表板显示了一段时间内的多个项目、响应代码、错误、热门页面、数据量、使用的浏览器、活动连接、丢失率等等。
2. 为你的 NGINX 日志提供基于 ML 的开箱即用异常检测作业。这些作业有助于根据请求率、IP 地址请求率、URL 访问、状态代码和访问者率异常来查明异常。
3. ES|QL 有助于在分析过程中处理日志并构建图表。
4. Elastic 的 GenAI Assistant 提供了一个简单的自然语言界面，可帮助分析所有日志，并可以从 ML 作业中提取问题，甚至创建仪表板。 Elastic AI Assistant 还会自动使用 ES|QL。
5. NGINX SLOs（Service Level Objectives）- 最后，Elastic 提供了定义和监控 NGINX 日志的 SLO 的能力。虽然大多数 SLO 都是基于指标的，但 Elastic 允许你创建基于日志的 SLO。我们在之前的博客中详细介绍了这一点。

NGINX 日志是日志为何很棒的另一个例子。日志记录是可观察性的重要组成部分，我们通常会考虑指标和跟踪。但是，应用程序和底层基础设施输出的日志量可能非常令人生畏，而 NGINX 通常是大多数分析的起点。

在今天的博客中，我们将介绍开箱即用的基于 ML 的异常检测作业如何帮助 RCA，以及 Elastic 的 GenAI Assistant 如何帮助轻松查看日志以在几分钟内查明问题。

先决条件和配置

如果你打算关注此博客，以下是我们用于设置此演示的一些组件和详细信息：

• 确保你在 Elastic Cloud 上有一个帐户和一个已部署的堆栈（请参阅此处的说明）。
• 在主机上启动 NGINX 服务器。或者运行以 NGINX 作为前端的应用程序并驱动流量。
• 安装 NGINX 集成和资产并查看文档中所述的仪表板。
• 确保你在 Elastic 堆栈中配置了 ML 节点
• 要使用 AI Assistant，你需要试用或升级到 Platinum。

在我们的场景中，我们使用来自 Elastic 环境的 3 个月的数据来帮助突出显示功能。因此，你可能需要在特定时间范围内运行具有流量的应用程序以进行跟踪。

使用 AI 助手分析问题

如上一篇博文所述，你可以通过 NGINX 日志的 SLO 监控收到问题警报。假设你有一个基于状态代码的 SLO，如上一篇博文所述。你可以立即通过 AI 助手分析问题。因为它是一个聊天界面，所以我们只需打开 AI 助手并进行一些简单的分析：（查看动画 GIF 了解演示）

AI 助手分析：

• Using lens graph all http response status codes < 400 and > =400 from filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer - 我们只想了解导致状态代码 >= 400 的请求数量并绘制结果图表。我们发现 15% 的请求未成功，因此触发了 SLO 警报。
• Which ip address (field source.adress) has the highest number of http.response.status.code >= 400 from filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer - 我们很好奇是否有特定的 IP 地址没有成功的请求。72.57.0.53，发生次数为 25,227 次，每日最高，但不能保证 2 次失败的请求。
• What country (source.geo.country_iso_code) is source.address=72.57.0.53 coming from. Use filebeat-nginx-elasticco-anon-2017. - 我们再次好奇这是否来自特定国家。IP 地址 72.57.0.53 来自 ISO 代码为 IN 的国家，对应于印度。没有什么不寻常的。
• Did source.address=72.57.0.53 have any (http.response.status.code < 400) from filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer - 奇怪的是，有问题的 IP 地址只有 4000 多个成功响应。这意味着它不是恶意的，并指向其他东西。
• What are the different status codes (http.response.status.code>=400), from source.address=72.57.0.53. Use filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer. Provide counts for each status code - 我们很好奇是否看到任何 502，虽然没有，但大多数失败都是 404。
• What are the different status codes (http.response.status.code>=400). Use filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer. Provide counts for each status code - 无论特定地址如何，状态代码出现次数 > 400 的最大次数是多少。这也指向 404。
• What does a high 404 count from a specific IP address mean from NGINX logs?？ - 提出这个问题，我们需要从我们的应用程序中了解造成这种情况的潜在原因。从答案中，我们可以排除安全探测和网络抓取，因为我们验证了特定地址 72.57.0.53 具有较低的非成功请求状态代码。它还排除了用户错误。因此，这可能指向断开的链接或缺失的资源。

观看流程：

潜在问题：

看来我们可能在后端提供特定答案时遇到问题，或者在资源方面遇到问题（数据库或断开的链接）。这是在诅咒高于正常的非成功状态代码> = 400。

AI 助手的主要亮点：

观看此视频时，你会注意到以下几点：

1. 我们使用一组简单的自然语言查询在几分钟内分析了数百万个日志。
2. 我们不需要了解任何特殊的查询语言。AI 助手使用了 Elastic 的 ES|QL，但也可以同样使用 KQL。
3. AI 助手轻松构建图表
4. AI 助手正在访问和使用存储在 Elastic 索引中的内部信息。与基于 “google foo” 的简单 AI 助手相比。这是通过 RAG 启用的，AI 助手还可以提出 github、运行手册和其他有用的内部信息中的已知问题。

查看以下博客，了解 AI 助手如何使用 RAG 检索内部信息。具体来说是使用 github 和运行手册。

使用 ML 定位异常

虽然使用 AI 助手非常适合分析信息，但 NGINX 日志管理的另一个重要方面是确保你可以管理日志峰值和异常。Elastic 有一个机器学习平台，允许你开发作业来分析特定指标或多个指标以查找异常。使用 NGINX 时，有几个开箱即用的异常检测作业。这些专门针对 NGINX 访问日志。

• Low_request_rate_nginx - 检测低请求率
• Source_ip_request_rate_nginx - 检测不寻常的源 IP - 高请求率
• Source_ip_url_count_nginx - 检测不寻常的源 IP - 高不同的 URL 计数
• Status_code_rate_nginx - 检测不寻常的状态代码率
• Visitor_rate_nginx - 检测不寻常的访问者率

开箱即用，让我们看看与我们之前的分析相关的作业 - Status_code_rate_nginx。

只需单击几下，我们就会立即获得一份分析报告，显示特定 IP 地址 72.57.0.53 的未成功请求数高于正常水平。奇怪的是，我们还发现这是使用 AI 助手。

我们可以与 AI 助手进行对话，查看日志，甚至查看其他 ML 异常作业，从而进一步了解情况。

结论：

你现在已经看到 Elastic 基于 RAG 的 AI 助手如何轻松地帮助分析 NGINX 日志，甚至无需了解查询语法、了解数据的位置，甚至了解字段。此外，你还看到了我们如何在出现潜在问题或服务质量下降 (SLO) 时提醒你。

查看有关 NGINX 日志的其他资源：

• 适用于 NGINX 的开箱即用异常检测作业
• 使用 NGINX 集成来提取和分析 NGINX 日志
• Elastic 中基于 NGINX 日志的 SLOs
• 使用 Elastic 基于 RAG 的 AI 助手将 GitHub 问题、运行手册和其他内部信息用于 RCA

试用

现有的 Elastic Cloud 客户可以直接从 Elastic Cloud 控制台访问其中的许多功能。没有利用云上的 Elastic？开始免费试用。

所有这些功能也可以在你的环境中实现。立即了解如何开始使用。

本文中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。

在这篇博文中，我们可能使用或提到了第三方生成 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制第三方工具，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害承担任何责任。将 AI 工具用于个人、敏感或机密信息时，请谨慎行事。你提交的任何数据都可能用于 AI 培训或其他目的。我们无法保证你提供的信息会得到安全或保密。在使用任何生成 AI 工具之前，你应该熟悉其隐私惯例和使用条款。

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

原文：NGNIX log analytics with GenAI in Elastic — Elastic Observability Labs