问题描述

我们将对与 Grafana Loki 存储有关概念进行进一步的学习，以阅读官方文档为主：
1）/Operations/Storage: Storage | Grafana Loki documentation
2）/Storage: Storage | Grafana Loki documentation

该笔记将记录：阅读官方文档而产生的学习笔记，以及相关问题的解决办法；

解决方案

Loki 需要保存两种数据：Chunk；Index；

Grafana Loki 仅索引标签（并不索引日志内容，这与其他日志系统不同），而日志内容则压缩存储，这两点使得 Loki 能够运维简单且成本低廉；

storage schema

/Operations/Storage/Storage schema | Grafana Loki documentation

Grafana Loki 运行其在运行期间切换日志存储，这里的“切换”是指“从某个时间点开始，将后续日志写入新的存储服务中”；

概念术语（⇒ Storage）

Loki，其收到的每条日志有三个组成部分：Tenant-ID；Label-Set；Log-Content；

Stream（流）

通过 Tenant-ID 与 Label-Set 参数，将日志分类为不同的 Stream；

Chunk（块）

针对同个 Stream 的日志条目，其被压缩为 Chunk（块）；

Ingester 接收日志条目，并追加（或创建）Chunk，并保存在内存中，最后周期（可配置）刷新到存储系统中；Loki 支持多种存储系统；

能够用于保存 Chunk 的存储有：
1）Amazon DynamoDB
2）Google Bigtable
3）Apache Cassandra
4）Amazon S3
5）Google Cloud Storage
6）Filesystem (please read more about the filesystem to understand the pros/cons before using with production data)
8）Baidu Object Storage

Index（索引）

在 Index 中，保存有 Steam 的 Label-Set，并且关联到相关的 Chunk；
Index 也保存在存储中，Loki 支持使用各种不同的存储来保存 Index；

能够用于保存 Index 的存储有：
1）Single Store (boltdb-shipper) – Recommended for 2.0 and newer index store which stores boltdb index files in the object store
2）Amazon DynamoDB
3）Google Bigtable
4）Apache Cassandra
5）BoltDB (doesn’t work when clustering Loki)

Storage（⇒ Operations/Storage）

日志删除（Log Entry Deletion）

Log Entry Deletion | Grafana Loki documentation

虽然按照官方文档操作，但是或许是我们操作错误或理解错误，我们始终未能成功删除日志。

Grafana Loki v2.5.0，目前（06/07/2022），日志删除处于实验性质，仅支持 BoltDB Shipper 索引存储。
支持以 Stream 和 Timestamp 来匹配要删除的日志；
Compactor 负责暴露 REST API，通过访问该 REST API 进行日志删除，但不会立即删除，实际的删除动作发生在 Cancellation Period 时间超时之后。

开启 Compactor 服务，才能进行相关操作：
1）配置 Helm Chart / compactor.enabled: true 来开启，同时 retention_enabled: true 才能开启日志删除；

进行相关日志操作：

# 提交删除任务
curl -X POST -g 'http://compactor.loki:3100/loki/api/admin/delete?match[]={foo="bar"}' # 根据 Stream 删除（匹配 Label 删除）

# 查看删除任务
curl -X GET 'http://loki-loki-distributed-compactor.loki:3100/loki/api/admin/delete'

# 取消删除任务
POST /loki/api/admin/cancel_delete_request

如果日志无法被删除，可能原因如下：
1）可能未导致删除任务执行的时间：Grafana Loki 有很多时间参数，超时或满足条件才会进行删除动作；
2）Compactor 的 shared_store 参数配置错误，导致无法找到正确的存储信息；我们的环境采用 shared_store: s3 配置；
3）其他参数或服务配置错误；

Filesystem

WIP

Retention（Table Manager / Compactor）

日志归档的处理：过久的日志可以进行删除或者归档，在 Grafana Loki 中，通过 Table Manager 或 Compactor 来实现。

我们选择的方案：根据官方文档，Compactor 将成为默认组件，并具有更精细的配置策略，并得到官方长期支持，所以我们将主要了解 Compactor 的使用方法。

目前 Compactor 仅支持 BoltDB Shipper Store 存储。
Compactor 需要以单实例运行；
Compactor 能对索引去重；
Compactor 被采用时，则没必要使用 Table Manager 组件；
压缩和保留两者都是幂等的，如果 Compactor 重启，将继续从停止的地方开始执行；

参数 compaction_interval 控制 Compactor 执行周期，每周期执行 Compaction 和 Retention 操作；如果落后则会尽快执行；

Single Store (boltdb-shipper)

Grafana Loki/Operations/Storage/Single Store (boltdb-shipper)

在 Loki 2.0 前，索引数据存储在单独的索引中；
在 Loki 2.0 中，引入新的索引机制，boltdb-shipper（Single Store Loki），该类性的索引仅需要单一的对象存储，同时用于保存索引与日志块；

通过 BoltDB Shipper 特性，Index 保存在 BoltDB File 中，并被同步到对象存储中（该对象存储同时用于保存 Chunk 数据）。同时 BoltDB Shipper 还负责将对象存储中的 BoltDB File 同步到本地，以获取由同个集群其他服务创建的 Index 条目；

在以 24h 为周期的 Index 文件中，BoltDB Shipper 工作良好，所以我们默认也采用此配置；

Storage schema

WIP

Table manager

WIP

Write Ahead Log

WIP

存储配置方式

在 Grafana Loki 中，存储是这样使用的：
1）首先，通过 storage_config 参数，来配置各种不同类型的存储；

2）然后，通过 schema_config 参数，来引用 storage_config 定义的某个存储：
—- schema_config/store 定义保存 Index 的存储；
—- object_store 定义保存 Chunk 的存储；

参考文献

Configuration | Grafana Loki documentation