Loki 分布式项目中为每个模块单独设置超时时间

在使用Loki + Grafana来做日志收集、展示时，往往会对每个项目的日志设置一组标签，例如:
A 模块：{job="A", level="info"}
B 模块：{job="B", level="info"}
C 模块：{job="C", level="info"}

假设其中C模块的日志量很大，例如是使用Netty开发的物联网通讯模块且设备数量较多时，这个项目模块每天会产生大量的日志，而相较于C的A和B则拥有较小的日志量。

由于存储空间的成本问题，现在我们需要进行细粒度的日志保留时长的设计，C保留7天的日志，A和B保留30天的日志。
此时，如果仍然使用基于Table Manager的日志保留--删除策略，则无法做到做到该需求，这里选择采用基于Compactor的日志保留策略。

以下是基于官方的示例说明：

compactor:
  working_directory: /data/retention
  shared_store: gcs
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
schema_config:
    configs:
      - from: "2020-07-31"
        index:
            period: 24h
            prefix: loki_index_
        object_store: gcs
        schema: v11
        store: boltdb-shipper

limits_config:
  retention_period: 744h
  retention_stream:
  - selector: '{job="C"}'
    priority: 1
    period: 168h

retention_enabled: true是必须写的，如果不写，Compactor 只会压缩表，不会启动保留策略。
retention_delete_delay: 2h是 Compactor 删除 marked chunks 的延迟时间，这里是出于相关引用的考虑。
retention_delete_worker_count: 150是 Compactor 删除chunk时，用到的线程数量
period: 24h这个值只能是24h，只有在为24h时，数据过期策略才会工作

retention_period是对全局生效的，retention_stream是对指定的Stream生效，
如果Stream匹配不到具体的selector，则会使用全局的过期时间

在使用如上提供的方式完成配置后，需要对loki进行重启，之后等待10~20分钟后过期的数据将无法被查询到