弃用

概述

参考：

BoltDB-Shipper 运行细节

Ingester 组件用于将 Index 与 Chunks 数据写入存储；Querier 组件用于从存储中读取 Index 和 Chunks 以处理 LogQL 查询请求。

写入数据

在深入了解细节之前，需要知道 Ingester 如何管理存储中的 Index 数据。

读取数据

Queriers lazily loads BoltDB files from shared object store to configured cache_location. When a querier receives a read request, the query range from the request is resolved to period numbers and all the files for those period numbers are downloaded to cache_location, if not already. Once we have downloaded files for a period we keep looking for updates in shared object store and download them every 5 Minutes by default. Frequency for checking updates can be configured with resync_interval config.查询者将 BoltDB 文件从共享对象存储延迟加载到已配置的 cache_location。 当查询器接收到读取请求时，该请求的查询范围将解析为期间号，并将那些期间号的所有文件下载到 cache_location（如果尚未下载）。 下载文件一段时间后，我们会继续在共享库中查找更新，默认情况下每 5 分钟下载一次。 可以使用 resync_interval config 来配置检查更新的频率。

To avoid keeping downloaded index files forever there is a ttl for them which defaults to 24 hours, which means if index files for a period are not used for 24 hours they would be removed from cache location. ttl can be configured using cache_ttl config.为了避免永久保存下载的索引文件，有一个 ttl，默认值为 24 小时，这意味着如果一段时间内未使用索引文件 24 小时，它们将从缓存位置中删除。 可以使用 cache_ttl config 来配置 ttl。

Note: For better read performance and to avoid using node disk it is recommended to run Queriers as statefulset(when using k8s) with persistent storage for downloading and querying index files .注意：为了获得更好的读取性能并避免使用节点磁盘，建议将 Queriers 作为 statefulset 运行（使用 k8s 时），并带有持久性存储，以下载和查询索引文件。

Table(表) 概念

参考：

• 官方文档，运维-存储-表管理器
• 开源中国博客，Loki|数据过期启动删除策略设计

Loki 可以将 Index 和 Chunks 数据以 Table(表) 的形式储存起来，凡是支持表结构的存储产品，都可以用来存储 Loki 的数据。使用 Table 时，会在一段时间内创建多个 Table，每个 Table 包含特定时间范围内的数据，所以 Table 也称为 Periodic Table(周期表)。

注意：表的概念不适用与存储在 S3 的 Index 与 Chunk 数据

如图所示，数据在存储中就是这样一种结构：

Loki 接收到的 Log Stream，会根据时间被分配到一个 Periodic Table 中

这是一种数据整合的方法，以便于更好的管理数。将数据基于表来进行分组有两个好处：

• Schema(模式) # 不同周期的表具有不同的 schema(模式) 和 版本。模式用来指定这个周期表内的数据使用什么类型的存储来存放数据。
• Retention(保留) # Retention 是通过删除整个表来实现的。
  • 通过将数据放在不同的周期内，在删除时也可以按照周期来删除，大大提高了数据处理效率

Table Manager(表管理器)

[!Notes] 仅当使用多存储后端时才需要表管理器。如果使用 TSDB（推荐）或 BoltDB（已弃用），则不需要表管理器。

Table Manager(表管理器) 是 Loki 的一个组件，用于创建和删除表。根据配置文件中 schema_config.configs 字段中的相关配置，在指定时间开始之前创建周期表，并在根据 table_manager 字段中的相关配置，将数据时间范围超过保留期的表内的数据删除

Table Manager 并不是可以管理所有存储类型中的日志流数据的，现阶段仅支持以下类型的存储：

• Index 数据
  • BoltDB Shipper
  • Cassandra
  • DynamoDB
  • ……等等，详见官方文档
• Chunk 数据
  • Cassandra
  • DynamoDB
  • Filesystem
  • ……等等，详见官方文档

注意：

• Table Manager 无法管理存放在对象存储(比如 S3)中的数据，如果要使用对象存储来储存 Index 与 Chunks 数据，则应该自行设置桶策略，以删除旧数据。

周期表存储相对于特定时间段的索引或块数据。在 schema_config 配置环境中配置储存在单个表中的数据的时间范围的持续时间及其存储类型。

schema_config 配置环境可以包含一个或多个配置。每个配置都定义了 .configs.from 字段指定的日期和下一个 .configs.from 配置之间这一段时间使用的存储模式，对于最后一个模式配置条目，则视为 .configs.from 指定的时间到当前时间这一段时间。这允许在一段时间内具有多个不重叠的架构配置，以便执行架构版本升级或更改存储设置（包括更改存储类型）。效果如下图： 写入路径将命中日志条目时间戳记所在的表（通常是最后一个表，除了靠近表末尾和下一个表的开头的短时间段外），而读取路径将命中包含查询数据的表时间范围。

表管理器会在配置中设定的开始时间之前创建新表，以确保一旦到达当前表的结束时间，新表就准备就绪。

Loki Storage Retention(数据保留)

官方文档：https://grafana.com/docs/loki/latest/operations/storage/retention/

Table Manager 可以实现 Loki 的 Retention(数据保留) 行为。如果想要启动 Retention，在 table_manager 配置环境中，需要开启删除数据保留的行为，以及确定数据可以保留的 period(期限，也就是时间范围)，详见 《Loki 配置详解》 table_manager 配置环境说明。

这个 Retention Period(保留期限) 是这么理解的：比如设置保留期限为 7d，表周期为 7d，那么当第三张表激活时，则第一张表被删除。 这种设计允许进行快速删除操作，但要以保留期限由表格周期控制为代价。所以 Retention 必须为 Period 的倍数，比如当表周期为 7 天时，那么要保留的就必须是 7 天、14 天、21 天…..这种。否则无法正确删除一整张表。像 14 天，21 天这种，其实就意味着保留 2 张表、3 张表。

这是一个保留 28 天 日志数据的配置示例：主要配置点在最后 6 行

schema_config:
  configs:
    - from: 2018-04-15
      store: boltdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb:
    directory: /loki/index
  filesystem:
    directory: /loki/chunks

chunk_store_config:
  max_look_back_period: 672h

table_manager:
  retention_deletes_enabled: true
  retention_period: 672h

这个示例效果如下，当第六张新表创建之后，最早的表就会删除，至少保留 28 天，4 张表。 注意：官方示例写的 30 天，是错误的，详见：https://github.com/grafana/loki/pull/2772