使用 Grafana Loki 和 MinIO 进行日志记录

这篇博文将解释 Grafana Loki 的基础知识，这是一个日志聚合系统，旨在存储和查询来自应用程序和基础设施的日志。我们将描述 Loki，解释其架构和用途，并讨论为什么 MinIO 对象存储是保存 Loki 数据的好地方。我们将在后续博文中提供有关如何使用 MinIO 存储 Loki 数据的教程。

日志提供有关设备和系统的基本信息。它们在企业中被用于无数用途。监控是一个关键的用例，涉及监视日志中的错误并在发生重大错误或超过错误率阈值时发送警报。日志是调试和故障排除信息的宝贵来源，并且在跟踪应用程序运行状况和崩溃时必不可少。日志可用于识别恶意活动并进行取证调查。日志还可用于商业智能，以提供洞察力并帮助制定业务增长战略。

日志总是在增长，使用传统企业存储对它们进行索引、搜索和存储可能会占用大量资源。为了减轻这种负担，日志搜索工具将数据存储在与 S3 兼容的对象存储中，例如 MinIO。这是一个更简单的架构，其中基于日志数据构建的应用程序受益于 MinIO 的大规模高吞吐量，以及版本控制、不变性和持久性。我们最近的基准测试使用 NVME 驱动器在 32 个节点上实现了 1.32 Tbps 的 PUT 吞吐量和 2.6 Tbps 的 GET 吞吐量。    

让我们深入了解洛基。

Grafana Loki简介

Grafana Loki是一个以 Prometheus 为蓝本的分布式多租户日志聚合系统。Loki 在2018 年西雅图 KubeCon 大会上宣布并在 AGPLv3 许可下发布，在云原生可观察性堆栈中占据突出地位，并经常与 Grafana 和 Prometheus 结合使用，以在单个 UI 中查看指标、日志和跟踪并发出警报。

将应用程序集 Grafana-Loki-Promtail 视为大致等同于 ELK 堆栈是有帮助的，Promtail 代理将日志发送（拖尾）到 Loki 数据存储并在 Grafana 中将它们可视化。Promtail 是一个日志收集器，它使用与 Prometheus 相同的服务发现，并包括在将日志发送到 Loki 之前标记、转换和过滤日志的类似功能。Loki 不索引日志文本，而是索引元数据。条目被分组到流中并使用标签进行索引。通常，管理员使用 Grafana 和 Loki 的查询语言 LogQL 来探索和可视化日志。他们还配置警报规则并将警报发送到 AlertManager 以进行路由。

Loki 是一种轻量级且具有成本效益的日志分析工具，因为它仅索引元数据。硬件要求远低于在内存中构建和存储索引的全文处理工具。您可以在自己的环境或云平台中本地运行 Loki，并随着运营的增长而横向扩展。与 Prometheus 和 Grafana 一样，Loki 可以轻松部署在 Kubernetes 上。  

Promtail 代理是为 Loki 设计的。它获取日志，将它们转换为流并通过 HTTP API 将流推送到 Loki。Loki 不仅限于 Promtail 代理——您还可以使用其他客户端发送日志，例如 Docker Driver、Fluentd、Logstash 和 Lambda Promtail。如果您已经在运行 Logstash 并想快速试用 Loki，那么能够将 Logstash 用作客户端会很方便。抓取 Kubernetes 和 Docker 容器日志的能力对于故障排除非常有帮助。

从 2.0 版开始，Loki 将数据存储在单个对象存储后端中。Grafana Labs之所以依赖对象存储，是因为它“快速、经济、简单，更不用说当前所有未来的发展所在了。” 这种模式依赖于适配器，boltdb_shipper将 Loki 索引存储在对象存储中。BoltDB Shipper允许您运行 Loki 而无需依赖外部数据库来存储索引。它在本地将索引存储在 BoltDB 文件中，并不断地将这些文件发送到对象存储，例如 MinIO。这简化了 Loki 部署，消除了潜在的故障点，并消除了运行外部数据库（如 Apache Cassandra、Google Bigtable 或 Amazon DynamoDB）的成本。

现代化日志存储范式

使用日志可能是一项资源密集型提议。即使日志支持多种用例，摄取、存储和查询日志数据的工作量也有可能超出价值。企业需要一种方法来降低存储和探索日志数据的复杂性——这就是对象存储，例如 MinIO。

企业竭尽全力存储日志并使其可供分析。他们部署了复杂的架构和流程来提高效率，例如将日志归档到冷存储、减少日志存储的持续时间、将日志汇总到不太详细甚至完全删除日志。

这些策略首先破坏了收集日志的目的。价值不在日志本身，价值在于日志的应用方式。日志包含解决性能问题、分析使用数据、了解客户偏好等所需的所有详细信息。许多行业要求保存日志以用于合规性和审计目的。然而，当存储如此繁琐以至于每条日志的价值都受到质疑时，应用日志解决问题的机会就变得有限了。

MinIO 可以存储和保护的日志量没有限制。MinIO 对对象的数量和组织没有任何限制，并通过跨多个节点和驱动器的纠删码来分发和保护它们。MinIO 的巨大性能促使许多企业将对象存储作为主存储来实现，以整合存储空间，迁移到云原生应用程序架构并获得灵活性、可移植性和弹性可扩展性。  

无限可扩展的日志对象存储

对于在日志管理方面苦苦挣扎的企业，诸如 MinIO 之类的对象存储提供了一个发展战略的机会。就大容量和高度复杂的日志数据所需的性能和可扩展性而言，很难击败对象存储。设计针对对象存储运行的应用程序堆栈允许企业将存储与计算资源分离，从而提高传统整体日志管理解决方案的效率。迁移到云原生架构可简化操作，同时扩展可用日志管理和分析工具的生态系统，例如 Humio、Cribl、Splunk、Elastic 等。

例如，在 MinIO 中保存和使用日志数据可以简化管理，同时显着增加可以应用此数据的用例数量。管理员不必制定详细的计划来考虑数据格式和大小，或者考虑快照和复制等数据保护的专有方法。必须以这种方式规划和管理存储会导致痛苦、过于复杂的结果，经常会增加运营开销。MinIO 抽象化了存储日志数据的挑战，在幕后处理数据保护，同时通过无处不在的 S3 API 公开数据。MinIO 为日志数据提供持久的对象存储，降低后端复杂性，同时简化和精简用例和驱动它们的应用程序。对于普通开发人员或应用程序最终用户，  

用于企业日志记录的 MinIO 和 Loki

将日志和 Loki 日志数据保存到 MinIO 有助于克服企业在管理大规模日志分析程序时面临的许多挑战。企业必须摆脱传统企业存储带来的限制，以实现 MinIO 提供的改进的性能、便携性和耐用性。消除过时存储模式的负担可以让开发人员腾出时间来构建分析和 AI/ML 应用程序，从而使企业能够释放日志的全部价值。