Grafana Loki 日志删除实操指南：从零配置到物理清理

Grafana Loki 日志删除实操指南：从零配置到物理清理

【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki

用 Grafana Loki 日志删除清理指定流和时间窗口的日志：配置 compactor、提交请求、跟踪进度、取消操作，一次讲清。

5 分钟跑通：最小配置加一条 curl

先让删除功能跑起来，细节后面再补。在 Loki 配置文件中加入：

limits_config: # retention_period: 744h # 想强制执行 retention 再开启 deletion_mode: filter-and-delete compactor: working_directory: /var/loki/compactor retention_enabled: true delete_request_store: gcs://your-delete-request-bucket # delete_request_store_db_type: boltdb # 默认值，可省略 # …其余字段保持默认

重启后，向 compactor 的 3100 端口提交一个删除请求：

curl -X POST -H "X-Scope-OrgID: tenant1" \ "http://loki-compactor:3100/loki/api/v1/delete?query=%7Bcluster%3D%22prod%22%7D&start=1704067200&end=1704153600"

看到204 No Content、响应头里带X-Delete-Request-ID，就说明删除请求已进入队列。注意：数据不是立刻消失，请求要走过取消保护期后，才由 compactor 真正执行删除。

配置项速查：哪些字段和删除相关

与 compactor 日志删除相关的全部配置项如下（默认值来自pkg/compactor/config.go）：

三个最容易混淆的点：delete_request_store是对象存储位置，delete_request_store_db_type只是本地引擎，两者不是一回事；delete_request_cancel_period给你留的取消窗口，retention_delete_delay是执行前的缓冲，别配反；retention 未启用时删除端点压根不存在，返回的是 400 而不是 403。

deletion_mode 三种模式怎么选

deletion_mode是limits_config中的全局设置，默认filter-and-delete，也可通过运行时配置文件按租户覆盖。⚠️ 拼写错误（比如写成filter_only）会在配置校验时直接报错，compactor 起不来。

limits_config: deletion_mode: filter-and-delete # 全局默认 # 也可在运行时配置文件中按租户覆盖

选型建议：合规要求"数据必须消失"时，最终一定要落到filter-and-delete；但第一次删大流量、或者还没把握查询条件够不够精确时，先切filter-only，用 Grafana 查询对比过滤前后的行数，确认命中范围符合预期再切物理删除。想彻底禁用某租户的删除能力，用按租户覆盖把它设为disabled即可。

操作实战：提交、跟踪、取消的完整时序

提交：四个参数都要过校验

提交时服务端会逐项校验，不合法直接 400：

• query（必填）：流选择器，可带行过滤器；语法或正则错误在提交时就会被拒，不会留到执行期才失败
• start/end（必填）：Unix 秒或 RFC3339；start 必须小于 end，且不允许删未来时间
• max_interval（可选）：只控制分片粒度，最小 1s，单位限s/m/h；不能大于delete_max_interval，也不能大于待删时间窗口本身
• 分片规则：只有带行过滤器的请求才会按delete_max_interval（或max_interval）拆成多个子请求，且分片之间刻意保留少量时间重叠，避免边界漏删；不带过滤器的请求不拆分

跟踪：GET 回来的状态怎么读

curl -H "X-Scope-OrgID: tenant1" \ "http://loki-compactor:3100/loki/api/v1/delete"

返回该租户全部删除请求的 JSON 数组，按创建时间排序，内部字段UserID、SequenceNum已隐藏。状态字段可能是Received、N% Complete或Processed——同一请求的多个子请求会被自动合并成一条展示，百分比按已完成子请求比例计算。可选参数：for_querytime_filtering=true只看查询过滤相关的请求；start+end按时间重叠过滤。

取消：保护期内随时可反悔

curl -X PUT -H "X-Scope-OrgID: tenant1" \ "http://loki-compactor:3100/loki/api/v1/delete?request_id=<REQUEST_ID>"

取消窗口就是delete_request_cancel_period（默认 24h）。窗口内、状态还是Received的请求随时可取消；一旦开始处理或已Processed，普通取消会被拒，必须加force=true强删；对超过取消期的请求，普通取消同样被拒。另有GET/POST /loki/api/v1/cache_generation_number两个缓存代数端点，删除完成后缓存代代会自动更新，一般不需要你手动碰。

一张链路图看懂删除怎么落地

1. 周期扫描：compactor 每个 retention 周期（apply_retention_interval，为 0 时等于 compaction 周期加抖动）扫描所有未处理的删除请求
2. 取消期过滤：只有创建时间已超过delete_request_cancel_period的请求才进入执行队列——这是给你留的反悔窗口
3. 批量执行：每周期最多处理delete_batch_size（默认 70）个请求，chunk 删除并发度由retention_delete_worker_count控制
4. chunk 重建写回：filter-and-delete模式下，带行过滤器的 chunk 会被读出、剔除匹配行、重建后写回对象存储并更新索引；纯选择器请求（无行过滤器）则直接删除整个 chunk
5. 缓存代数更新：请求标记为Processed，租户的 cache generation number 自动递增，查询结果缓存随之失效，不会再把已删数据缓存回来

🔧 记住一点：带行过滤器的删除是 compactor 最重的活，CPU 和 IO 都是密集型的。要在多个租户、大时间范围上做这类删除，参考 compactor 横向扩展文档，把工作分散到多个 compactor 实例上。

避坑清单

• ⚠️ 对象存储先开版本控制（versioning）——retention 配错时，这是你唯一的后悔药
• 只想删数据、不想真的执行 retention 策略？把retention_period设为0s，再开retention_enabled
• 先用filter-only观察命中范围，确认无误后再切filter-and-delete
• 删大数据量时给提交请求带上max_interval控制分片粒度，避免单个子请求跨度过大拖长执行时间
• 盯住loki_compactor_deletion_*指标：请求积压、处理进度、失败次数都能看，必要时扩容 compactor
• 删除请求本身也存放在对象存储里（delete_request_store），这个桶同样要有备份策略
• 从boltdb迁到sqlite时，配backup_delete_request_store_db_type: boltdb双写，迁移完再摘掉备份
• 租户级限制：想封掉某租户的删除能力，用运行时配置按租户覆盖deletion_mode: disabled，而不是动全局配置

配置上 retention，配好 delete_request_store，deletion_mode 选对，删除请求就会穿过取消保护期，被 compactor 定期物理清理。更多细节可参考 docs/sources/operations/storage/retention.md。

【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki