现有Loki部署如何从Table-manager切换至Compactor

你提交的修改版配置存在缩进错误、缺少必要配置项，无法正常实现chunks按规则自动删除的效果，具体修正方式如下：

现有修改版本的问题 #

• YAML缩进完全不规范：prometheus、loki配置块缩进层级错误，limits_config下的retention_period缩进错位，直接应用会导致Loki配置加载失败。
• 缺少compactor工作目录配置：compactor需要持久化存储删除任务的进度、标记状态，未配置工作目录时，Pod重启后会重复扫描全量数据，甚至触发删除逻辑异常。
• 配置项取舍有误：原配置中已失效的table_manager相关配置需要完全移除，但chunk_store_config.max_look_back_period属于查询范围控制配置，和保留删除逻辑不冲突，可以保留使用。

修正后可直接应用的配置 #

grafana:
  enabled: true
  persistence:
    enabled: true
    size: 5Gi
  adminPassword: Vfgfhdjdkdisynwtey678CMX7xghuy879

prometheus:
  enabled: true
  alertmanager:
    persistentVolume:
      enabled: true
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 10Gi

loki:
  enabled: true
  persistence:
    enabled: true
    size: 70Gi
  config:
    chunk_store_config:
      max_look_back_period: 672h
    compactor:
      working_directory: /data/compactor
      retention_enabled: true
      retention_delete_delay: 2h
      retention_delete_worker_count: 20
    limits_config:
      retention_period: 672h

补充注意事项 #

• 你当前使用的是2.5.0版本单二进制单副本部署，不需要额外部署其他组件，上述配置生效后compactor会自动在Loki进程内运行，执行过期chunk删除逻辑。
• retention_delete_worker_count不需要设置为150：该参数是为分布式部署对接对象存储的场景设计的，你使用本地持久化存储时，worker数设10-20即可，数值过大会抢占正常业务读写的IO资源。
• 配置生效首次启动时，compactor不会立刻删除数据，会先全量扫描现有所有chunk，扫描耗时和当前存储的数据量正相关，首轮扫描完成后才会开始清理超期数据。
• 配置更新完成后需要滚动重启Loki Pod，新配置才会生效。

内容的提问来源于stack exchange，提问作者Golide