随着越来越多的应用程序迁移到云端，越来越多的遥测数据（日志、指标、跟踪）被收集，这有助于提高应用程序性能、运营效率和业务 KPI。然而，考虑到生成的大量数据，分析这些数据非常繁琐和耗时。传统的警报和简单的模式匹配（视觉或简单搜索等）对于 IT 运营团队和 SRE 来说是不够的。这就像大海捞针。
在这篇博文中，我们将介绍 Elastic 的一些用于根本原因分析的 IT 运营人工智能 (AIOps) 和机器学习 (ML) 功能。
Elastic 的机器学习将通过提供异常检测并通过时间序列分析和日志异常值检测来精确定位潜在的根本原因，从而帮助您调查性能问题。这些功能将帮助您减少在大海中找到“针”的时间。
Elastic 的平台使您可以快速开始使用机器学习。您不需要拥有数据科学团队或设计系统架构。此外，无需将数据移动到第三方框架进行模型训练。
可观测性和安全性的预配置机器学习模型是可用的。如果这些模型在您的数据上效果不佳，工具中的向导会指导您完成配置自定义异常检测和使用监督学习训练模型所需的几个步骤。为了帮助您入门，Elastic 可观测性中内置了多个关键功能，以帮助进行分析，从而无需运行特定的 ML 模型。这些功能有助于最大限度地减少日志的分析时间和时间。
让我们回顾一下这些内置的 ML 功能
异常检测：当启用时（请参阅文档），Elastic 可观测性通过连续建模您的时间序列数据的正常行为（学习趋势、周期性等）来自动检测异常，从而实时识别异常、简化根本原因分析并减少误报。异常检测在 Elasticsearch 中运行并与之一起扩展，并包含一个直观的用户界面。
日志分类：使用异常检测，Elastic 还可以快速识别日志事件中的模式。日志分类视图不会手动识别类似的日志，而是列出已根据其消息和格式分组的日志事件，以便您可以更快地采取行动。
高延迟或错误事务：Elastic 可观测性的 APM 功能可帮助您发现哪些属性导致事务延迟增加，并识别哪些属性在区分事务失败和成功方面最具影响力。此功能的概述在此处发布：Elastic 可观测性中的 APM 相关性：自动识别缓慢或失败事务的可能原因。
AIOps 实验室：AIOps 实验室使用高级统计方法提供两种主要功能
- 日志峰值检测器可帮助识别日志速率增加的原因。通过使用分析工作流视图，可以轻松查找和调查异常峰值的原因。检查给定数据视图的日志速率直方图图表，并查找可能跨多个字段和值的数百万个日志事件中特定变化的原因。
- 日志模式分析可帮助您查找非结构化日志消息中的模式，并使您更容易检查数据。它对数据视图的选定字段执行分类分析，基于数据创建类别，并将其与显示每个类别分布的图表和与该类别匹配的示例文档一起显示。
_ 在本博客中，我们将介绍针对 Google 开发的，最近由 OpenTelemetry 修改的流行“Hipster Shop 应用程序”的异常检测和日志分类。 _
高延迟功能的概述可以在此处找到，AIOps 实验室的概述可以在此处找到。
在本博客中，我们将检查一个场景，在该场景中，我们使用异常检测和日志分类来帮助识别 Hipster Shop 中问题的根本原因。
先决条件和配置
如果您计划遵循本博客，以下是我们用来设置此演示的一些组件和详细信息
- 确保您在 Elastic Cloud 上有一个帐户，并且在 AWS 上部署了一个堆栈（请参阅此处的说明）。在 AWS 上部署此项需要 Elastic Serverless Forwarder。
- 利用一个非常流行的 Hipster Shop 演示应用程序的版本。它最初由 Google 编写，用于展示跨多种可用变体的 Kubernetes，例如 OpenTelemetry 演示应用程序。Elastic 版本可以在此处找到。
- 确保您已为 Elastic APM 代理或 OpenTelemetry 代理配置了应用程序。有关更多详细信息，请参阅以下两篇博客：Elastic 中使用 OTel 的独立性和 Elastic 中使用 OTel 的可观测性和安全性。此外，请查看 Elastic 中的 OTel 文档。
- 浏览一下 Elastic 可观测性 APM 功能的概述。
- 浏览我们的 日志异常检测文档和日志分类文档。
一旦您使用 APM（Elastic 或 OTel）代理检测了您的应用程序并将指标和日志提取到 Elastic 可观测性中，您应该会看到如下所示的应用程序的服务地图
在我们的示例中，我们引入了一些问题来帮助您了解根本原因分析功能：异常检测和日志分类。根据您加载应用程序和/或引入特定问题的方式，您可能会有不同的异常和日志分类。
作为演练的一部分，我们将假设我们是管理生产中此应用程序的 DevOps 或 SRE。
根本原因分析
虽然应用程序已正常运行一段时间，但您收到通知，表明某些服务不健康。这可能是由于您在 Elastic 或其他外部通知平台中设置的通知设置（包括与客户相关的问题）引起的。在此实例中，我们假设客户支持已收到多起客户关于该网站的投诉。
作为 DevOps 或 SRE，您如何调查此事？我们将介绍 Elastic 中的两种途径来调查此问题
- 异常检测
- 日志分类
虽然我们单独显示这两种路径，但它们可以结合使用并且是互补的，因为它们都是 Elastic 可观测性提供的工具，可帮助您排除故障并确定根本原因。
机器学习用于异常检测
Elastic 将基于历史模式检测异常，并识别这些问题的可能性。
从服务地图开始，您可以看到用红色圆圈标识的异常，当我们选择它们时，Elastic 将提供异常的分数。
在这个示例中，我们可以看到 Hipster Shop 应用程序中的 productCatalogService 的特定异常分数为 96。异常分数表示与之前看到的异常相比，该异常的重要性。有关异常检测结果的更多信息，请点击此处。我们还可以深入研究异常并分析详细信息。
您将看到 productCatalogService 的平均事务延迟时间出现严重峰值，这正是服务地图中检测到的异常。Elastic 的机器学习已经识别出特定的指标异常（在单个指标视图中显示）。很可能客户正在对网站的缓慢做出反应，并且公司正在损失潜在的交易。
接下来要采取的一个步骤是，在一个更大的范围查看我们在服务地图中看到的所有其他潜在异常。使用异常浏览器查看已识别的所有异常。
Elastic 正在识别许多存在异常的服务。productCatalogService 的得分最高，其他一些服务，如 frontend、checkoutService、advertService 等，也具有较高的得分。但是，此分析仅查看一个指标。
Elastic 可以帮助检测所有类型数据中的异常，例如 Kubernetes 数据、指标和跟踪。如果我们分析所有这些类型（通过我们在 Elastic 机器学习中创建的各个作业），我们将看到更全面的视图，了解可能导致此延迟问题的原因。
一旦选择了所有潜在的作业并按 service.name 排序，我们可以看到 productCatalogService 仍然显示较高的异常影响者分数。
除了图表给我们提供异常的视觉效果外，我们还可以查看所有潜在的异常。您会注意到，Elastic 还对这些异常进行了分类（请参阅“类别示例”列）。当我们滚动浏览结果时，我们注意到来自分类的潜在 postgreSQL 问题，该问题也具有 94 的高分。机器学习已经识别出“罕见的 mlcategory”，这意味着它很少发生，因此指向客户所见问题的潜在原因。
我们还注意到，此问题可能由 pgbench 引起，pgbench 是一种流行的 postgreSQL 工具，可帮助对数据库进行基准测试。pgbench 反复运行相同的 SQL 命令序列，可能在多个并发数据库会话中运行。虽然 pgbench 绝对是一个有用的工具，但不应在生产环境中使用，因为它会对数据库主机造成繁重的负载，很可能导致网站上出现更高的延迟问题。
虽然这可能不是最终的根本原因，但我们已经相当快地识别出一个很可能成为根本原因的潜在问题。一位工程师可能打算针对暂存数据库运行 pgbench 以评估其性能，而不是生产环境。
机器学习用于日志分类
Elastic Observability 的服务地图检测到一个异常，在本演练的这一部分中，我们采取不同的方法，从服务地图调查服务详细信息，而不是最初探索异常。当我们探索 productCatalogService 的服务详细信息时，我们看到以下内容：
服务详细信息正在识别几件事：
- 与服务的预期范围相比，存在异常高的延迟。我们看到最近的延迟高于正常水平（高达 1 秒的延迟），而平均延迟为 275 毫秒。
- 与高延迟同一时间段内，失败率也很高（左下方图表“ 失败事务率 ”）。
- 此外，我们可以看到事务，其中一个特定的 /ListProduct 事务具有异常高的延迟，并且失败率也很高。
- 我们看到 productCatalogService 依赖于 postgreSQL。
- 我们还看到所有与 postgreSQL 相关的错误。
我们可以选择深入研究日志并在 Elastic 中进行分析，或者我们可以使用一种功能来更轻松地识别日志。
如果我们转到 Elastic Observability 中“日志”下的“类别”并搜索 postgresql.log，以帮助识别可能导致此错误的 postgresql 日志，我们会发现 Elastic 的机器学习已自动对 postgresql 日志进行了分类。
我们注意到另外两项：
- 存在一个与 pgbench 相关的较高计数类别（消息计数为 23,797，异常值高达 70）（在生产环境中看到此类别很奇怪）。因此，我们在“类别”中进一步搜索所有与 pgbench 相关的日志。
- 我们看到一个关于终止连接的奇怪问题（计数较低）。
在调查第二个严重错误时，我们可以看到错误发生前后的“类别”中的日志。
此故障排除显示 postgreSQL 发生 FATAL 错误，数据库在错误发生前关闭，并且所有连接终止。考虑到我们识别出的两个直接问题，我们认为有人正在运行 pgbench，这可能使数据库过载，从而导致客户看到的延迟问题。
接下来的步骤可能是调查异常检测和/或与开发人员合作审查代码，并将 pgbench 识别为已部署配置的一部分。
结论
我希望您已经了解 Elastic Observability 如何帮助您进一步识别并更接近地查明问题的根本原因，而无需寻找“大海捞针”。以下是经验教训和您所学内容的快速回顾：
-
Elastic Observability 具有多种功能，可帮助您缩短查找根本原因的时间并改进您的 MTTR（甚至 MTTD）。特别是，我们在这篇博客中回顾了以下两个主要功能：
- 异常检测：当启用时（请参阅文档），Elastic 可观测性通过连续建模您的时间序列数据的正常行为（学习趋势、周期性等）来自动检测异常，从而实时识别异常、简化根本原因分析并减少误报。异常检测在 Elasticsearch 中运行并与之一起扩展，并包含一个直观的用户界面。
- 日志分类：通过使用异常检测，Elastic 还可以快速识别日志事件中的模式。日志分类视图不会手动识别相似的日志，而是列出已根据其消息和格式分组的日志事件，以便您可以更快地采取措施。
-
您了解了使用 Elastic Observability 的日志分类和异常检测功能是多么容易和简单，而无需了解机器学习（有助于驱动这些功能），也无需进行任何冗长的设置。准备好开始了吗？注册 Elastic Cloud，试用我上面概述的功能。
其他日志资源
- 开始使用 Elastic 上的日志记录（快速入门）
- 通过集成摄取常见的已知日志（计算节点示例）
- 集成列表
- 将自定义应用程序日志摄取到 Elastic 中
- 在 Elastic 中丰富日志
- 通过 异常检测 (ML) 和 AIOps 分析日志