利用 Splunk 对人工智能数据基础设施进行 Spelunk 分析

概述

在企业数据方面，MinIO Enterprise Object Store 和 Splunk 有着共生关系。Splunk在其数字流处理器中使用MinIO。MinIO 是一个 Splunk SmartStore 端点。MinIO Enterprise Object Store 是一个高性能、兼容 Amazon S3 的分布式对象存储系统。通过遵循超大规模计算提供商的方法和设计理念，MinIO Enterprise 为私有云中的各种工作负载提供高性能和可扩展性。由于 MinIO Enterprise 专为仅服务对象而构建，因此单层架构可以毫不妥协地实现所有必要的功能。这种设计的优点是对象服务器既高性能又轻量级。在这篇文章中，我们将解释如何使用 Splunk 的高级日志分析来帮助理解 MinIO Enterprise 对象存储的性能和管理的数据。企业版的 MinIO 具有缓存功能，可以大大加快数据访问速度，这将帮助您快速检索频繁访问的数据。查看 AI 建立在对象存储上的真正原因，我们将深入探讨 MinIO 在 AI/ML 生态系统中的使用方式和原因。

MinIO 企业通知 101

MinIO Enterprise 允许管理员配置各种类型的通知，包括审计日志（提供有关集群内发生的任何 API 活动的详细信息，例如创建新存储桶、添加或删除对象、listBucket 调用等）和 MinIO Enterprise 服务器日志，它提供有关服务器上发生的错误的详细信息。在 MinIO Enterprise，我们相信简单性是可以扩展的，这一理念延伸到我们的日志记录。我们只记录严重错误。信息和警告级别日志记录只会使日志中充斥着白噪声，而白噪声很少（如果有的话）有帮助。鉴于这种方法，我们知道如果我们在 MinIO Enterprise 中看到错误，那就是需要解决的问题。Splunk可以帮助我们理解和优化MinIO Enterprise的性能。使用 Splunk 强大的日志分析工具，我们可以深入了解 MinIO Enterprise 集群中发生的情况，以及其中的数据发生的情况。

设置 Splunk HTTP 事件收集器

Splunk 允许将事件直接收集到 http（s）端点，他们称之为 HEC，即 HTTP 事件收集器（在此处记录）

这需要几个简单的步骤。配置 HEC 全局设置，创建令牌，并配置您希望数据驻留在的索引。

在 Splunk Web UI 中，转到设置 -> 数据输入 -> HTTP 事件收集器

在“全局设置”下，将“所有令牌”设置为“已启用”，并将默认源类型更改为_json

其他设置可以默认保留。由于这是一个未启用 TLS 的测试环境，因此我们将在保存并继续之前取消选中“启用 SSL”框。

完成此操作后，单击“新建令牌”并按照向导进行操作。

在向导的下一页“输入设置”中，单击“创建新索引”

对于名称，请选择一个名称，例如 minio_audit。

将默认索引更改为您刚刚命名的索引，并确保它显示在右侧的“所选项目”框中，以确保您的事件转到新创建的索引。

点击查看并提交，您将看到新创建的令牌

复制此值以在下一步中使用。您可以稍后通过转到设置 -> 数据输入 -> HEC 来查看此令牌

Splunk 配置现已完成。我们可以使用 curl 测试并确保一切正常，然后再进入 MinIO Enterprise 方面。

curl http://localhost:8088/services/collector/raw -H "Authorization: Splunk 2d30fe74-f448-4fc4-9522-6679e5377658" -d '{"event": "hello world"}'

{"text":"Success","code":0}

请注意末尾的“成功”状态。现在我们可以通过搜索 index=“minio_audit” 来查看该事件。

现在我们知道我们使用了正确的令牌，并将数据发送到正确的索引。

配置 MinIO Enterprise 审计通知

在验证 HEC 端点是否已正确配置后，我们可以使用 mc 查看审计通知的现有配置。

首先，让我们看一下使用 mc 的所有可能配置。

有很多配置选项，但现在我们只关心audit_webhook。我们将使用它来告诉 MinIO Enterprise 将其事件发送到 Splunk。

首先，让我们看一下已经配置的内容：

mc admin config get myminio audit_webhook audit_webhook enable-off endpoint auth_token=

在这里，我们看到 audit_webhook 未启用，并且没有定义终结点或auth_token。现在让我们使用从 Splunk 获得的值来执行此操作。

mc admin config set myminio audit_webhook enable=on

endpoint=http://localhost:8088/services/collector/raw auth_token="Splunk

2d30fe74-f448-4fc4-9522-6679e5377658"

Setting new key has been successful.

Please restart your server with `mc admin service restart myminio`.

正如消息所述，我们需要重新启动 MinIO Enterprise 集群，这可以通过 mc 工具完成。当服务器重新启动时，我们可以验证设置是否正确。

mc admin config get myminio audit_webhook

audit_webhook

endpoint=http://localhost:8088/services/collector/raw auth_token="Splunk 2d30fe74-f448-4fc4-9522-6679e5377658"

到目前为止，一切看起来都是正确的。首先，让我们看一下设置中的存储桶。如果您尚未配置存储桶，则可以使用 mc mb myminio/mybucket 创建一个存储桶。在这里，我们有一个简单的测试设置：

mc ls myminio/

[2020-05-12 11:17:28 PDT]         OB testevents/

只是一个名为“testevents”的存储桶

现在，让我们将一个对象上传到该存储桶

touch mytestobject

mc cp mytestobject myminio/testevents

返回到 Splunk 搜索界面并搜索此对象，可以看到审计通知：

与任何审计日志记录一样，事情可能会变得非常健谈。我们可以通过在 Splunk Web UI 中使用此搜索来过滤掉大量噪音，从而去除所有典型的日常内容：

现在，我们已经过滤掉了管理员可能一直在执行的所有日常操作，例如列出存储桶。现在，这将向我们展示我们可能最关心的事情，例如正在创建或删除的对象或存储桶。让我们进一步研究日志。

以这个例子为例，当我使用搜索词 index=“minio_audit” AND statuscode NOT 200 时可以看到：

这是一个与典型的 PutBucket 略有不同的事件。从此事件的 api： name 字段中，我们知道有人正在尝试创建新的存储桶。当我们查看状态时，我们会看到 Conflict 和 statusCode： 409。这意味着有人尝试创建存储桶，但它已经存在。也许有人不小心重新运行了脚本或命令来尝试创建该存储桶。本身并不一定是什么大不了的。但是，如果我在一天内看到数千个这样的代码，我可能在某个地方运行了一些低效的代码，我可以使用这些信息来进一步调查。

我们可以深入研究其他一些有趣的领域。

deploymentid - 如果我正在运行多个 MinIO Enterprise 集群，我可以使用它来深入到特定集群

服务器 - 查找为请求运行的 MinIO Enterprise 服务器的版本。

TTFB/TTFR - 可用于查找请求花费的时间何时超过预期。

请注意，即使是响应标头也会被记录下来，因此您可以判断是否存在附加到对象的自定义元数据。

配置 MinIO Enterprise Logger 通知

了解用户和应用程序在集群中执行的操作非常重要。但是，如果知道集群本身发生了什么呢？为此，我们可以将 Splunk 配置为 MinIO Enterprise logger_webhook的端点。如果您还记得我们之前的 mc admin config get myminio 输出，还有一个名为 logger_webhook 的字段，用于将 MinIO Enterprise 服务器日志发送到端点。首先，我们看一下配置的内容：

mc admin config get myminio logger_webhook Logger_webhook enable-off endpoint= auth_token=

现在，我们将配置设置为与 audit_webhook 相同的配置。尽管您可以使用相同的 HEC 令牌和索引，但您可能希望通过创建新的 HEC 令牌和索引来将数据放入其中，从而将它们分开。我更喜欢这种方法，因此您会注意到令牌发生了变化，但命令的其余部分保持不变。由于我创建了一个新索引，因此对这些日志事件的搜索将针对 index=“minio_logs”。

之后不要忘记重新启动以使配置生效。

请记住，从以前开始，MinIO Enterprise 不会记录任何不需要操作的内容，因此我们需要尝试创建某种故障才能看到某些事情发生。首先，让我们看一下我们如何运行此测试的服务器。我用来启动服务器的命令如下：

minio server /tmp/splunk/{1...4}

这模拟了服务器的多磁盘设置，这意味着擦除代码和 bitrot 保护已打开。默认情况下，MinIO Enterprise 纠删码可以处理 n/2 个磁盘丢失，并且仍然可以读取数据。如果我们看一下后端文件系统，我们会看到类似这样的事情：

简而言之，有四个文件夹（“磁盘”），每个文件夹都包含我们之前上传的 mytestobject 的一定数量的数据或奇偶校验。让我们从“删除”其中两个“磁盘”开始（请记住，在此测试环境中，这些不是真正的磁盘，只是文件夹路径，但删除它们模拟将磁盘从正在运行的服务器中拉出）。

rm -rf /tmp/splunk/{1..2}

现在我们的树命令显示情况很糟糕。

我们设置中的一半“磁盘”是空的。让我们看看 Splunk 中记录了什么。

MinIO Enterprise 报告说，它看到一些空磁盘，并显示字段消息：找到未格式化的磁盘。在典型的生产设置中，丢失几个磁盘（甚至几台服务器）并不是什么大问题，因为 MinIO Enterprise 是为处理大规模故障而构建的。但是，在我们微小的测试设置中，我们已经丢失了一半的磁盘，如果我们丢失了更多磁盘，我们将无法访问数据。现在我们知道我们在寻找什么，我们可以配置 Splunk 以直观地调用此类事件。在“设置”->“事件类型”（在“知识”标题下）中，创建新的事件类型。对于我们的测试，我们将像这样设置它：

现在，当我们在minio_logs索引中浏览事件时，我们将看到一个巨大的红色横幅，让我们知道我们配置的未格式化磁盘事件在这里，需要注意。在大规模部署中，MinIO Enterprise 将通过启动修复过程自动纠正这种情况。在大规模部署中我可以等待，但在这里我不想冒这个险，所以我会在 MinIO Enterprise 服务器上手动启动递归修复。

现在修复已经完成，我们验证后端数据是否完好无损。

一切都恢复了正常，我们可以继续我们的一天。

结论

Splunk在企业中越来越普遍。随着机器数据的增加，他们的部署激增，目前他们有成千上万的客户。一种是将 MinIO Enterprise 用作 SmartStore 端点 - 降低 Splunk 成本，同时实现额外的规模 - 所有这些都不会牺牲性能。另一种方法是利用 Splunk 行业领先的日志分析功能来优化 MinIO Enterprise 部署的性能。两者都提供了充分利用数据的能力 - 通过保护数据、从数据中学习并从中提取价值。自己试一试。如果您需要一些帮助，请查看我们的文档。