从日志文件中检测异常：大规模使用案例中的性能

采用最佳技术来推动竞争优势，将优秀的运营商与优秀的运营商区分开来。 发现公司数据中的隐藏宝藏，然后向客户展示关键的可操作见解，将有助于为客户创造一项不可或缺的服务，而这难道不是每个高管都希望创造的吗？

基于云的数据存储（由 Amazon S3、Google Cloud Storage 和 Azure Blob Storage 等领导）以其简单性和可扩展性取代了传统的 文件和块存储。 我记得我的朋友 Peter Bramm 博士（Luster 的创始人）在 1990 年代后期谈论过星际文件系统，这是一个对象存储平台，但系统 的复杂性限制了其部署到大型 DOE/DOD 集群。 数据的爆炸式增长和 Amazon S3 协议的简单性改变了存储格局，如今对象存储 是从数据库到分析和 AI/ML 工作负载的所有内容的主要存储。

基于云的对象存储使组织能够轻松地将数据迁移到云，但是公共云部署的经济性需要持续关注。 膨胀的账单综合症导致许多组织从公共云启动数据回迁。 鉴于 MinIO 与 AWS S3（以及 GCP/Azure）兼容，我们已成为寻求对其部署（本地和公有云）进行更多控制的组织的首选对象存储。 数据可以证明这一点 - MinIO迄今为止已有超过 13 亿次 Docker 拉取次数，每天的拉取次数接近 100 万次。

对于 MinIO 最大的企业客户（想想数百 PB 的数据），我们已经开始看到一些模式出现。 在这篇博文中，我将重点介绍一个特定的用例，即来自日志文件的异常检测，该用例贯穿全球三个最大的企业：一家信用卡支付处理商、一家领先的网络安全公司和一家云超大规模企业。 此用例突出了对结构化数据的实时机器学习以检测异常。

企业数据战略

在深入机器学习之前，了解企业数据管道的三种阶段至关重要：摄取、存储和消费。

在这种情况下，数据摄取是指来自各种来源的输入管道，例如事务性应用程序或批处理进程，包括 ETL（提取、转换和加载）和 ELT（提取、加载和转换）馈送。

数据存储应被视为整个企业的共享资产，并应用适当的身份和访问管理策略。 通过将企业数据集中在一个地方，组织可以确信数据存在单一的事实来源，而无需昂贵且不必要的复制（需要数据协调，昂贵）。

数据消费应侧重于按需向消费者交付可信数据。 可以应用广泛的分析工具和机器学习算法来推动分析，因为见解会传递给消费者。

使用 MinIO 的此数据管道的逻辑视图如下所示

日志分析

现代企业每天会从各种日志（服务器消息、网络设备、应用程序和用户交易）中生成数百 TB 的数据。 这些日志可能提供有关错误、访问模式、数据库运行状况或数百种其他类型的复杂 IT 环境的见解。 这些日志对于企业安全（通常在 CISO 组织下）和其他企业 IT 组织提供关键服务至关重要。

在单个机器级别，Linux 提供一项名为 Systemd-journald 的服务。 Systemd-journald 服务收集并存储日志数据（此信息来自各种来源，例如内核日志消息、系统日志、审计日志、网络日志等）。 Linux 提供了一个框架，允许任何应用程序根据需要指向此服务并记录事件。

过去，IT 团队必须手动从多个来源聚合这些日志并搜索模式以发现操作问题。 随着企业复杂性的不断发展，手动搜索这些日志以获取情报的过程变得不可能。 这催生了由 Splunk、ELK 或 Humio 等组织/项目领导的下一代日志分析。 这些项目内部工作机制的细节超出了这篇博文的范围，但可以肯定地说，从数十万个来源收集日志到集中式存储库，然后过滤、搜索和可视化这些数据对于网络安全至关重要。 上述工具可以帮助组织提供操作情报，即通过分析机器生成的数据来获取见解的能力。 操作情报工具使用户能够对聚合数据运行复杂查询，并可视化和报告结果。 想想数十万个 Systemd-journald 日志聚合在一个地方，提供实时情报。

日志数据的增长与企业以前所见过的任何东西都不一样，而且由于知识的宝藏很少见但非常宝贵，因此他们收集了所有可能的日志数据。 这迫使操作情报工具将日志数据存储在像 Amazon S3 这样的云存储中，因为没有单个服务器部署可以管理开始出现的数据量。 例如，Palo Alto Networks 创建了一个名为 Panorama 的日志记录工具，该工具从其下一代防火墙收集日志，其虚拟设备的默认存储空间为 500 GB。 存储空间几乎在发布后就过时了。 根据IDC 在 2021 年发布的一项研究，61% 的企业每天收集 1 TB 以上的安全日志数据。 由于大型组织的日志数据很快就会填满任何单个设备的所有可用存储空间，因此基于云的日志数据存储成为一项必要。 我们评估过的所有操作情报工具都附带了本机 S3 对象存储支持，并且只需要更新一个简单的配置变量即可。

鉴于云是一种运营模式，而不是一个地方，MinIO 已成为许多企业首选的 S3 对象存储平台。 原因有很多，但最常被提及的原因包括

• MinIO 提供 100% 与 S3 兼容的存储，无论是在本地还是在所有公共云（不只是 Amazon）。
• 由于成本考虑，从公共云存储到本地存储的数据回迁势头强劲，尤其是在从云中访问或迁移数据时会产生数据传出费用。
• 大量企业数据是在边缘产生的，将其迁移到公共云存储既费时又费钱。
• 对延迟敏感的应用程序可以从更接近企业应用程序的数据本地性控制中获益。
  

实时 ML 和异常检测的理由

实时异常检测，主要使用机器学习，已成为 MinIO 的一个杀手级用例。 异常检测识别不符合正常业务模式的数据点或事件。 它用于解决各种业务问题，例如欺诈检测、医疗诊断、网络入侵检测和制造缺陷检测。 机器学习使能够在大型数据集上实时自动执行异常检测。

在机器学习兴起之前，企业依赖一系列规则来从操作数据中过滤出疑似异常，但这些技术会产生太多误报，而且资源密集（这意味着速度慢），因此无法分析每天收集的海量数据。 在海量结构化（交易）和非结构化（文本、视频、音频、图像）数据中检测异常并非易事。 除了机器学习，根本没有办法以这种规模和速度检测异常。

检测异常的工作不仅仅是在数据子集中检测异常，如果能够实时地检测流数据的异常，那么它就会变得非常有用。 也就是说，数据量是巨大的。 实时分析的严格要求需要能够大规模执行的工具。 正如我们所写的那样，在 TB 级数据上实现高性能很容易，在 PB 级或 EB 级数据上实现高性能要困难得多。 这就是日志文件异常检测所面临的挑战类别。

我的 MinIO 同事已经详细地记录了 ML 流和异常检测，因此我不会再赘述，但您可以查看这些博客。

我在某个地方读到，“异常是指当输入经过适当训练的自动编码器后，自动编码器预测结果与真实值（在本例中为输入向量）之间出现高 MSE（均方误差）的情况。这种高 MSE 表明输入向量可能与自动编码器训练时使用的示例不相似。它在某种程度上有所不同——它是一种异常。不是好，也不是坏，只是与自动编码器训练时使用的數據显著不同。”

企业在选择对象存储以支持异常检测时，选择 MinIO 的原因如下：

• 高性能数据摄取，能够及时捕获相关实时数据，不会延误。
• 高性能读取操作，能够通过自动机器学习分析、实时搜索和警报来实现安全/欺诈保护。
• 能够线性扩展以满足不断增长的数据摄取和分析需求。
• 高可用性、容错性和数据持久性，确保异常检测系统在出现意外情况时能够持续提供保护。
• 滚动更新，可以执行非破坏性升级和修补。
• PB+ 容量，可以收集和保留来自越来越多的来源所需的数据。系统存储的数据越多，机器学习算法就越能利用这些信息来区分正常事件和异常事件。
• 强劲的传输中和静止加密，不会影响性能。
• IAM 和 PBAC，可以保护异常检测系统免受潜在的恶意行为。
  

客户用例

我在博客开头提到的三位客户，其数据摄取率每天在 10TB 到 100TB 之间。每个客户的数据摄取率每年大约增长 30% 到 100%。过去，这些客户都使用基于 HDFS 的存储进行日志聚合，但他们决定出于以下原因放弃这种旧的架构：

• 现代 AI/ML 堆栈中只有一小部分支持 HDFS，因为几乎所有现代应用程序都采用优先使用 S3 对象存储的策略。
• HDFS 的原始存储与可用存储的比率（在最佳情况下）至少比基于 MinIO 的对象存储的等效容错率高 33%。
• 运行 HDFS 集群所需的节点数量以及维护 HDFS 集群所需的专职工程师数量，是 MinIO 所需数量的 300%。一个较小的 9.4PB 部署需要 98 个 HDFS 数据节点（再加上额外的名称节点等），而 MinIO 则只需要 32 个节点（包括数据中心容错所需的节点）。
• HDFS 定价也是这些决策的一个因素。
  

以下图表显示了 HDFS 与 MinIO 的典型部署架构。

这些部署通常需要使用Kafka（所有链接均指向我们博客上的其他内容）来摄取流式数据，并使用NiFi 或Spark 来摄取批处理数据。MinIO 还具有针对传统应用程序的原生FTP/SFTP 服务器 功能。典型的Splunk 日志摄取管道可能如下所示：

由于具体的实现细节可能会因特定的技术和需求而异，因此务必参考 Kafka、MinIO 和 Splunk 附加组件的官方文档，以确保您遵循最佳实践并利用最新的功能和功能。

结果

那么这种方法为客户带来了什么？在一个案例中，该客户已经停止向 Amazon S3 的服务提供数据，而是将他们的日志数据指向 MinIO。在这种情况下，数据量非常大（数百 PB），因此这种改变将企业的毛利率提高了数百个基点。在另一个案例中，在从 HDFS 迁移后，该客户能够将基础设施成本（以服务器衡量）降低 84%。这包括存储和计算的分离，以及计算节点的性能提升和存储节点的密度提高。工作负载性能提高了三分之一以上，管理所需的专职人员减少了 87%。在第三个用例中，该客户启用了七个全球数据中心，拥有超过 10PB 的生产数据。从 HDFS 的转变使硬件占用空间减少了 50%，管理所需的人员减少了 60%。考虑到部署规模，每年节省的金额相当可观。

总结

将企业从 HDFS 迁移到对象存储以进行日志文件的异常检测，可以带来巨大的性能、成本和可管理性优势。更重要的是，这种用例在几乎所有企业中都存在。如果您想更深入地了解，请通过hello@min.io与我们联系，我们可以分享更多用例细节。如果您想自己尝试，请在此下载 MinIO 并立即开始使用。