用了Loki的同学都知道，日志存储在Loki里主要分为两部分，日志原始文件以及日志索引。按照Loki数据的设计思路，日志原始文件可以存放在任何文件系统中，可以是filesystem，对象存储等。而日志的索引则专门存储到索引服务当中，这里面包含Loki内置的BoltDB当中。其数据存储主要的思想也是让对象存储负责廉价地存储压缩日志，而索引则负责以快速，有效的查询方式存储这些标签。

当前Loki1.6版本支持的数据存储如下：

• Chunks 日志原始文件
• Cassandra
• GCS
• File System
• S3
• 任何实现S3标准接口的服务，如Minio，Ceph RGW
• Index 日志索引
• Cassandra
• BigTable
• DynamoDB
• BoltDB

我们先看先来看下Loki默认情况下关于数据存储配置

schema_config:
  configs:
  - from: 2018-04-15
    store: boltdb
    object_store: filesystem
    schema: v9
    index:
      prefix: index_
      period: 168h
storage_config:
  boltdb:
    directory: /data/loki/index
  filesystem:
    directory: /data/loki/chunks

storage_config

Loki的存储引擎配置，这个区块里面，主要定义的是各类存储的一些基本信息。只要你愿意，甚至可以把Loki支持的数据存储都加上，当今天小白子只拿filesystem、S3来做原始日志存储，boltdb和cassandra来做index存储

schema_config

这里面主要定义的是Loki数据存储的策略。从默认的配置里面可以得到的信息是Loki里面保存的是2018年4月15日之后的数据，同时原始文件存在filesystem中，index存在boltdb当中且保存的周期是168小时

更新Schema享受丝滑般切换

Loki对于数据存储的目标是向后兼容，通过修改Schema配置允许以增量方式升级到新的存储模式。首先，我们需要在schema_config中创建一个新的configs条目，要记住的是新加的存储模式起始时间必须是将来的某个时间点，这样Table Manager就可以在之前创建所需的表，并确保不会查询现有数据。否则在查询时会因丢失旧的日志索引造成无法检索。

小白举个例子，例如我们先把2020年9月10日之后的Loki日志切换到cassandra和S3上，那么按照如下配置后，重启服务即可

schema_config:
  configs:
  - from: 2018-04-15
    store: boltdb
    object_store: filesystem
    schema: v10
    index:
      prefix: index_
      period: 168h
  - from: 2020-09-10
    store: cassandra
    object_store: aws
    schema: v11
    index:
      prefix: index_
      period: 720h
    chunks:
      prefix: chunks_
      period: 720h

storage_config:
  boltdb:
    directory: /data/loki/index
  filesystem:
    directory: /data/loki/chunks
  cassandra:
    username: cassandra
    password: cassandra
    addresses: cassandra
    auth: true
    keyspace: lokiindex
  aws:
    s3: s3://<accessKey>:<secretKey>@<s3_url>/<buckets>
    s3forcepathstyle: true

对于2020年9月10日之前保存的所有数据，Loki使用v10的schema，到点之后就采用v11的schema策略来存储日志。我们只关心Loki新数据的保留策略，而以前的配置几乎不变。这样就大大简化了我们的升级过程。怎么样，切换就是这么丝滑，对吗？

Loki数据留存

默认情况下，原始日志文件除了使用filesystem的存储有周期删除旧日志文件外，Loki的其他chunk存储均不会删除旧日志文件 。如果你跟小白一样日志的原始文件存储在S3上，那么我们可以直接找到旧的文件删除，这个动作仅仅只会影响我们查询不到这个时间区域的日志内容。

如果你的Loki存储用了table-based的存储服务，那么日志的留存策略就会受到Table Manager的节制.

Table Manager是Loki的一个组件，主要负责在其时间段开始之前创建周期表，并在其数据时间范围超出保留期限时将其删除。它当前支持的后端包含如下

• Index 日志索引
• Amazon DynamoDB
• Google Bigtable
• Apache Cassandra
• BoltDB (primarily used for local environments)
• Chunk 日志原始文件
• Amazon DynamoDB
• Google Bigtable
• Apache Cassandra
• Filesystem (primarily used for local environments)

由于具有破坏性，默认情况下Table Manager功能被禁用。我们可以在配置中显式启用数据删除策略并将其保留期设置为大于0

table_manager:
  retention_deletes_enabled: true
  retention_period: 336h

小白提醒，按照官方说法table_manager和storage_config中的数据周期时间必须为24h的倍数才能获得正确的生效

关于云原生小白

云原生小白的创号目的是将平日里离大家较远云原生应用以实用的角度展现出来，站在小白的角度来看待和使用云原生，并以每篇文章解决一个实际问题的出发点带领大家走进云原生世界。