今日实践：Loki丝滑般的数据切换

正文共：2463字 预计阅读时间：7分钟

用过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的倍数才能获得正确的生效

--- end ---