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

2024年11月6日   |   by mebius

作者:来自 ElasticBahubali Shetti

%title插图%num

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(ServiceLevelObjectives)- 最后,Elastic 提供了定义和监控 NGINX 日志的 SLOs 的能力。虽然大多数 SLOs 都是基于指标的,但 Elastic 允许你创建基于日志的 SLOs。我们在之前的博客中详细介绍了这一点。

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

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

先决条件和配置

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

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

使用 AI Assistant 分析问题

上一篇博文所述,你可以通过 NGINX 日志的 SLO 监控收到问题警报。假设你有一个基于状态代码(status codes)的 SLO,如上一篇博文所述。你可以立即通过 AI Assistant 分析问题。由于它是一个聊天界面,我们只需打开 AI Assistant 并进行一些简单的分析:(请参阅动画 GIF 了解演示)

AI Assistant 分析:

  • Using lens graph all http response status codes =400 from filebeat-nginx-elasticco-anon-2017. http.response.status.code is not an integer – 我们只想了解导致 status code >= 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 – 奇怪的是,有问题的 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?– 提出这个问题,我们需要从我们的应tgcode用程序中了解造成这种情况的潜在原因。从答案中,我们可以排除安全探测和网络抓取,因为我们验证了特定地址 72.57.0.53 具有较低的非成功请求状态代码。它还排除了用户错误。因此,这可能指向断开的链接或缺少资源。

观看流程:

%title插图%num

潜在问题:

似乎我们可能在后端提供特定答案时遇到问题,或者在资源(数据库或断开的链接)方面遇到问题。这导致非成功 status codes 高于正常值> = 400。

AI 助手的主要亮点:

观看此视频时,你会注意到以下几点:

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

查看以下博客,了解 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。

%title插图%num

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

我们可以进一步与 AI 助手对话,查看日志,甚至查看其他 ML 异常作业。

结论:

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

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

试用

现有的 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 Obsetgcodervability Labs

文章来源于互联网:使用 Elastic 中的 GenAI 进行 NGINX 日志分析

Tags: , , , ,