可观测性革命推动了计算、安全、基础设施和可审计性方面的巨大进步。企业可观测性提供对云原生系统的全面和精细的可见性,以更快地识别和解决问题。遥测数据(指标、日志、跟踪、运行状况检查)可以实时显示和关联,从而提供从最高管理层到安全团队的整个组织的上下文。
市场上有一些极好的解决方案,但它们有一个潜在的弱点——它们在很大程度上是通用的。市场所缺乏的,以及我们所构建的,是专门为大规模对象存储部署而设计的可观测性解决方案。MinIO Enterprise Object Store 可观测性功能提供了一个全新而全面的故障排除工具,以确保所有数据管道的功能和性能。此视角简化了 MinIO 操作和故障排除,是专为 MinIO 构建的完整监控解决方案,包括指标、日志、跟踪和全面的审计日志等。它在商业层 Enterprise Lite 和 Enterprise Plus 产品/服务中可用。
MinIO 一直具有可观测性,依靠插件连接到所有行业标准的可观测性解决方案。我们通过行业标准 API 支持所有领先的解决方案。例如,我们一直有一个 Prometheus API 端点来提供指标,并使用各种 Grafana 仪表板来可视化它们。我们将继续支持这些工具,但我们可以为我们的客户做得更好。我们了解 MinIO 的工作原理、它生成的数据(例如日志和指标)以及如何将它们可视化。
几年前,当您拥有一个整体式应用程序时,调试和诊断相当容易,因为可能只有一个服务有几个用户。如今,系统被分解成更小的微服务,部署在 Kubernetes 之上的容器中,在不同云环境中的多个集群中。在这种分布式环境中,需要观察所有情况,包括整体情况,如果需要的话,在更精细的层面上。
MinIO的企业可观测性大致可以分为三个子类别:日志记录、指标和跟踪。在这篇博文中,我们将向您展示在新的或现有的 MinIO 应用程序中设置这些组件是多么简单。
让我们通过浏览每个菜单项并解释我们为什么这样做以及为什么它很重要来了解一下:
数据映射
数据映射指标允许我们查看任何一组驱动器,甚至低至纠删码级别,从而确定驱动器利用率、容量和性能。下面的屏幕截图显示了已使用和可用的数据量。重要的是,它显示了脱机或处于修复状态的驱动器数量,您可以轻松检查这些驱动器的数量,以确保集群在修复基础结构时仍可以处理请求。
审计
审核日志捕获所有系统调用和系统活动以及所有用户活动。它还捕获其他用法,例如系统和用户。除其他活动外,了解对整个集群进行了哪些更改以及上传到网络的内容变得非常重要。审核日志是所有这些信息所在的位置。
错误
错误日志显示内部进程的问题。故障驱动器或即将脱机的驱动器是两个示例。它还记录其他高级问题,例如带有 lambda 通知或复制的问题。错误日志显示无法连接的驱动器和具有随机读取问题的驱动器的问题。这些问题相当罕见,但当它们确实发生时,我们可以以易于理解的方式捕获和呈现它们。
指标
在硬件组件级别,有多个应用程序指标图形和仪表可用于监视扫描程序、修复和 ILM。一些可用的指标包括:
-
自启动以来扫描完成的存储桶
-
自服务器启动以来扫描的存储桶已启动
-
在当前自我修复运行中治愈的物体
-
在当前自愈运行中罐装的对象
API
大部分流量将通过 S3 API 指标进行。因此,在访问 MinIO 集群时,有必要监控发出的请求、拒绝的请求和整体流量的速率。
API 是最重要的方面之一。这使您可以大致了解如何访问数据以及对数据的总体访问。您每分钟获得多少次读取和写入,如果请求存在延迟,即使是毫秒,也可以显示出来。甚至可以将 API 指标添加到散热器类型仪表板中以查看最新数据。
系统
MinIO严重依赖两个主要的硬件相关组件,因此非常关注:驱动器和网络。虽然由于数据存储在物理介质上,硬盘性能可能是更明显的问题,但承认网络在整体性能中发挥的重要作用至关重要,尤其是在分布式环境中。虽然默认复制的异步特性可能允许您设置它并忘记它,但您还需要知道集群是否落后于其数据复制。监控这些系统以及适当的 CPU 和健康的内存量非常重要。
康复
MinIO 会自动修复因静默位腐烂损坏、驱动器故障、驱动器更换或 PUT/GET 上的其他问题而损坏的对象。MinIO 还执行定期背景对象修复。在下图中,您可以看到在自我修复运行期间扫描和修复的对象。治疗会自动治疗因驱动器损坏、驱动器故障和其他硬件故障而损坏的对象。您可以使用在自我修复运行期间散落的对象的图形查看服务状态。
生命周期管理
生命周期管理数据可为您的企业带来对模式和警报的可见性。这有助于您进行进一步的分析。例如,如果要检查今年的某些趋势,可以通过绘制生命周期管理图表来获取报告。生命周期管理是关于转换数据或删除数据的规则。我们的建议是在那里创建一个单独的“永不删除”应用程序,并为此使用生命周期管理。因此,如果您希望能够监控系统中的生命周期管理规则的情况,那么这里就是您的不二之选。
复制
MinIO 包括多种复制数据的方法,因此您可以选择最佳方法来满足您的需求。我们已经在博客中介绍了基于存储桶的主动-主动复制,用于在存储桶级别复制对象,以及用于复制存储桶中特定对象的批量复制,这为您提供了更精细的控制。
无论是站点复制还是存储桶复制,都应监视活动复制工作线程的数量及其队列,以确保没有积压的对象堆积以将数据传输到远程站点。这有助于在积压工作 (backlog) 变得太大以及复制速度变慢时跟踪并查看警报。
在这里,您将看到积压的复制工作。
扫描器
Scanner 是特定于 MinIO 的调试工具,用于监控和修复整个系统中的对象。扫描程序提供群集所需的元数据信息,以报告系统管理的数据和对象的总量。
调试
跟踪
跟踪是用于描述记录和观察应用程序发出的请求的活动的术语,以及这些请求如何在系统中传播。当系统以分布式方式设置时,我们称之为分布式跟踪,因为它涉及通过多个系统观察应用程序及其交互。例如,作为开发人员,您的代码可能包含多个 API 调用,但您更感兴趣的是 MinIO 函数的执行时间以及这些函数在应用程序中使用时的相互依赖性。跟踪将通过以下方式提供必要的见解:
-
识别性能和延迟瓶颈
-
重大事故后查找根本原因分析
-
确定多服务体系结构中的依赖关系
-
监视应用程序中的事务
实时跟踪显示应用程序的行为方式。他们逐个调用查看内部调用,以确定中断和流程、每次调用花费的时间、传输了多少字节、确切的操作、成功/失败。跟踪使运营团队能够快速了解系统中是否存在问题,然后深入分析根本原因。例如,如果应用程序超时,可以快速确定罪魁祸首是慢速驱动器。还有一个用于实时测试的实时跟踪工具。
总结
现在,DevOps团队可以成为存储专家,即使他们不知道对象存储是如何运行的。他们拥有所需的所有工具——单一管理平台显示美国东部的数据中心驱动器出现故障。IT 团队在他们的通用硬件仪表板中看到了这一点,DevOps 在 MinIO 中看到了这一点。当您认真维护数据基础架构时,您可以采取此步骤。但不要误会我们的意思,这不是一个 IT 工具。这是一个数据基础架构工具,而不是一个低级存储工具。
对于任何基础设施,尤其是像存储这样的关键基础设施,至关重要的是,系统必须以合理的阈值进行监控,并尽快发出警报。不仅要监控和警报,还要对数据进行长期分析。例如,假设您突然注意到您的 MinIO 集群占用了大量空间,那么知道这些空间量是在过去 6 小时、6 周还是 6 个月内占用的,这是否很好?基于此,您可以决定是否需要添加更多空间或修剪现有的低效使用空间。
我们在构建一切时都考虑到了简单性和可扩展性,我们致力于提供极简主义的专用软件工具。我们构建并支持 MinIO。您可以在 MinIO Enterprise Observability 中获得此打包。可观测性非常简单,因为我们为您消除了复杂性。我们不是收集大量多余的数据,而是收集重要数据 - 这是存储高效的存储监控。该系统轻巧且易于使用,因为我们只收集所需的数据,然后为您查明异常情况。您无需自定义,您只是享受我们自以为是的界面。
另一种思考方式是,合规团队需要多年的一点细节,而运营团队需要几周的大量细节。MinIO 的可观测性功能提供了后者,因为通用解决方案不能,因为它们不能很好地理解数据基础设施。MinIO 的解决方案是为运营用例构建的 - 具有极高的粒度。粒度和细节节省了运营团队的时间和资源,并减少了停机时间。
您可能想知道,“为什么我要在 Prometheus 和 Grafana 上使用类似 Observability 的东西?使用 Prometheus 和 Grafana,您需要编排和配置多个组件才能使事情正常进行。您必须先将指标/数据发送到 Prometheus,然后连接到 Grafana 以可视化数据。这只是一个例子——Grafana 生态系统肯定还有更多的活动部件。借助企业可观测性,数据存储和可视化组件捆绑在一起,就像 MinIO 一样。