使用 Splunk 监控 MinIO - 教程

概述

在企业数据方面，MinIO 和 Splunk 存在着共生关系。Splunk 在其数字流处理器中使用 MinIO。MinIO 是 Splunk SmartStore 的一个端点。

在这篇文章中，我们将解释如何使用 Splunk 的高级日志分析来帮助理解 MinIO 对象存储套件及其管理数据的性能。对于那些刚接触我们和/或 Splunk 的人，这里做一个快速概述。

MinIO 是一个高性能、与 Amazon S3 兼容的分布式对象存储系统。通过遵循超大规模计算提供商的方法和设计理念，MinIO 为私有云中的各种工作负载提供了高性能和可扩展性。由于 MinIO 是专门为服务对象而构建的，因此单层架构无需妥协即可实现所有必要的功能。这种设计的优势在于，对象服务器既具有高性能又轻量级。

Splunk 是一个用于企业计算环境的高性能事件处理平台，可提供对 IT 运营的关键性和及时性洞察，包括来自物联网、防火墙、Web 服务器等的数据。Splunk 最近引入了一项名为 SmartStore 的功能，使 Splunk 能够将 PB 级数据卸载到外部与 Amazon S3 兼容的对象存储中。分离计算和存储使 Splunk 节点能够专注于索引和搜索，而对象存储则可以专注于数据的管理、弹性和安全性。虽然这篇文章重点介绍如何使用 Splunk 管理 MinIO 上的通知和日志，但您可以查看我们关于 SmartStore 的详细文章这里。

MinIO 通知 101

MinIO 允许管理员配置各种类型的通知，包括审计日志（提供有关集群内发生的任何 API 活动的详细信息，例如创建新的存储桶、添加或删除对象、listBucket 调用等）和 MinIO 服务器日志，这些日志提供有关服务器上发生的错误的详细信息。

在 MinIO，我们相信简单性可以扩展，并且这种理念也扩展到我们的日志记录中。我们只记录关键错误。信息和警告级别的日志记录只会用很少（如果有的话）有帮助的噪声淹没日志。鉴于这种方法，我们知道如果我们在 MinIO 中看到错误，则需要解决该错误。

Splunk 可以帮助我们理解和优化 MinIO 的性能。利用 Splunk 强大的日志分析工具，我们可以深入了解 MinIO 集群内部发生了什么，以及驻留在其中的数据发生了什么。

设置 MinIO

在本演示中，我们需要运行一个 MinIO 服务器（或集群），并且我们将使用 MinIO 客户端 (mc) 对该服务器执行管理操作。要配置 MinIO 服务器，请参阅快速入门指南。

https://docs.min.io/docs/minio-quickstart-guide.html

有关设置 mc 的信息，请参阅 mc 快速入门指南

https://docs.min.io/docs/minio-client-quickstart-guide.html

设置 Splunk HTTP 事件收集器

Splunk 允许将事件直接收集到 http(s) 端点，他们将其称为 HEC，即 HTTP 事件收集器（文档 这里）

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

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

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

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

完成后，点击“新建令牌”并按照向导操作。

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

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

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

点击审查并提交

您将看到新创建的令牌

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

Splunk 配置现已完成。在继续进行 MinIO 方面的工作之前，我们可以使用 curl 进行测试并确保一切正常。

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 审计通知

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

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

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

首先，让我们看看已经配置了什么

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

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

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

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

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

返回到 Splunk 搜索界面并搜索此对象，向我们显示审计通知

与任何审计日志一样，事情可能会变得非常冗长。我们可以使用 Splunk Web UI 中的此搜索过滤掉许多噪音，这些噪音来自所有典型的日常事务

现在，我们已过滤掉管理员可能执行的所有日常操作，例如列出存储桶。这现在将向我们显示我们可能最关心的内容，例如创建或删除的对象或存储桶。让我们进一步调查日志。

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

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

我们可以深入挖掘的其他一些有趣的字段。

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

Server - 查找为请求运行的 minio 服务器版本。

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

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

配置 MinIO 日志记录器通知

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

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

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

还记得之前说过，MinIO 不会记录任何不需要操作的内容，因此我们需要尝试创建某种类型的故障才能看到某些事情发生。首先，让我们看看我们如何运行此测试的服务器。我用来启动服务器的命令如下

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

这模拟了服务器上的多磁盘设置，这意味着擦除码和比特腐烂保护已开启。默认情况下，MinIO 擦除编码可以处理丢失 n/2 个磁盘，并且仍然可以读取数据。

如果我们查看后端文件系统，我们会看到类似这样的内容

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

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

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

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

MinIO 报告它看到一些带有字段 message: unformatted disk found 的空磁盘。在典型的生产环境中，丢失几个磁盘（甚至几个服务器）不是什么大问题，因为 MinIO 构建用于处理大规模故障。但是，在我们这个小型的测试设置中，我们丢失了一半的磁盘，如果我们再丢失任何磁盘，我们将无法访问数据。现在我们知道了要查找的内容，我们可以配置 Splunk 以直观地指出此类事件。在“设置”->“事件类型”（在“知识”标题下），创建一个新的事件类型。对于我们的测试，我们将按如下方式设置它

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

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

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

结论

Splunk 在企业中越来越普遍。随着机器数据的兴起，它们的部署激增，并且目前拥有数万名客户。鉴于 MinIO 类似的增长轨迹，这两种软件解决方案很可能在企业中共存。这创造了机会。

一个是使用 MinIO 作为 SmartStore 端点 - 降低 Splunk 成本，同时实现额外扩展 - 所有这些都不会牺牲性能。另一个是利用 Splunk 领先的行业日志分析功能来优化 MinIO 部署的性能。

两者都提供了充分利用数据的能力 - 通过保护数据、从中学习并从中提取价值。自己尝试一下。如果您还没有 MinIO，您可以在这里下载。如果您需要一些帮助，请查看我们的文档。您还可以查看我们的公共 Slack 频道。