正文共：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默认情况下关于数据存储配置
代码语言：javascript复制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上，那么按照如下配置后，重启服务即可
代码语言：javascript复制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
代码语言：javascript复制table_manager:
retention_deletes_enabled: true
retention_period: 336h
注意按照官方说法
table_manager和storage_config中的数据周期时间必须为24h的倍数才能获得正确的生效
