Loki 保留策略是什么
Loki 的保留策略决定日志保存多久：由 compactor 组件执行删除，retention_period 设定全局期限；使用对象存储时还必须显式开启删除能力并指定删除请求存储，否则到期数据不会被真正清掉。保留期与查询侧的时间范围限制是联动的——默认会拒绝过旧时间范围的查询，因此缩短保留期之前要先确认对复盘与审计的影响。
基本信息
| 关键配置 | limits_config.retention_period、compactor.retention_enabled、compactor.delete_request_store |
|---|---|
| 执行组件 | compactor |
| 对象存储要求 | 需开启删除能力并指定存储类型 |
| 典型取值 | 720h 表示保留 30 天 |
| 适用版本 | Loki 2.x / 3.x |
典型使用场景
- 成本控制：按数据价值分层设定保留期，热数据长留、调试日志短留
- 合规要求：审计类日志按法规要求保留足够时长
- 容量规划：按日增量与保留期估算存储规模
- 迁移调整：从自建存储迁到对象存储后重新校准保留与删除配置
- 排障验证：确认 compactor 是否真的在执行删除，而不是只改了配置
使用要点
- 缩短保留期不会追溯恢复已删除的数据，先确认合规要求
- 对象存储必须开启删除能力，否则删除请求不会真正生效
- 单机文件系统存储上跑保留要留意磁盘与权限，避免删除任务静默失败
- 保留期与查询时间范围限制要对齐，避免出现查得到却删不掉的矛盾
- compactor 的运行状态与错误日志都要纳入监控
保留配置
保留配置
# 全局保留 30 天
limits_config:
retention_period: 720h
compactor:
retention_enabled: true
delete_request_store: s3 # 需与对象存储类型一致
# 自建文件系统存储仅建议用于测试环境
# 改完要确认 compactor 实际在删除，而不是只改了配置配置项读法
| 配置项 | 作用 | 注意 |
|---|---|---|
| retention_period | 全局保留时长 | 按数据价值分层设置 |
| retention_enabled | 开启保留删除 | 未开启则数据一直留着 |
| delete_request_store | 删除请求存储 | 需与对象存储类型一致 |
| compactor 运行状态 | 执行删除的组件 | 不运行则策略形同虚设 |
| 查询时间范围限制 | 拒绝过旧查询 | 与保留期一起规划 |
缩短保留期是不可逆的：已经删除的数据无法通过改回配置恢复，调整前先确认合规与复盘的实际需求。