Grafana Loki 日志删除实操配置、API 与避坑全解【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki合规要求把敏感信息从日志里抹掉可分布式日志系统不是删个文件就行。Grafana Loki 的日志删除功能让你通过 compactor 提交请求保护窗口过后才真正抹除数据。几段 YAML 加几条 curl 命令就能跑通。什么能删什么不能删场景与边界先说清楚什么时候需要删日志合规擦除用户要求删除其个人数据对应的时间段必须真的消失测试数据清理压测流量混进了生产流要按时间窗口清掉敏感信息误入库密码、token 被打进日志需要尽快消除Grafana Loki 能删的粒度是日志条目一行一行。一个删除请求由三个要素构成流选择器如{clusterprod}、起止时间窗口、可选的 LogQL 行过滤器如| ERROR。它做不到的是不能删掉流本身不能改动索引的既有结构更不会实时生效——提交之后有一段保护窗口窗口内还能反悔。 索引类型有硬约束TSDB 索引完整支持新部署的标准选择BoltDB Shipper也支持删除但已废弃并将在 Loki 4.0 移除别在新环境上选它删除由 compactor 组件承载它在整体架构里的位置如下图单体模式下所有组件跑在同一个 Loki 二进制里三步开启删除功能Loki 日志保留与删除共用同一套底座删除能力构建在 compactor 的 retention日志保留到期自动清数据工作流之上。开启它只需三步打开 retention 开关compactor: retention_enabled: true只有开关打开时删除 API 端点才会被注册。关闭状态下无论deletion_mode取什么值任何租户都访问不了删除接口。命令行等价写法是-compactor.retention-enabledYAML 键与命令行 flag 一一对应前缀都是-compactor.后文不再重复。配置删除请求桶delete_request_store指定一个对象存储桶用来存放删除请求的数据文件。retention 一旦启用这一项就是必填——留空时 compactor 启动校验直接失败进程起不来。确认deletion_mode不是disabled它是limits_config里的全局与按租户设置默认值filter-and-delete意味着开箱即删。想限制某个租户时在运行时配置文件中做按租户覆盖即可。⚠️安全警告开 retention 要谨慎。强烈建议同时在对象存储上开启版本控制——retention 配置写错时还能从版本历史把数据捞回来。如果只想要删除能力、不想强制执行日志保留把retention_period设为0s。与删除相关的核心配置项如下定义见 pkg/compactor/config.go配置项默认值一句话说明retention_enabledfalseretention 与删除功能的总开关delete_request_store空存放删除请求的桶启用后必填delete_request_store_key_prefixindex/请求数据在桶内的路径前缀delete_request_cancel_period24h删除请求的保护窗口可取消时长delete_max_interval24h带行过滤器请求的最大跨度超出自动拆分delete_batch_size70每个周期最多处理的删除请求数retention_delete_delay2hchunk 真正删除前的额外缓冲retention_delete_worker_count150删除 chunk 的并发工作协程数一个最小可用配置示例limits_config: retention_period: 744h # 不想强制保留就改成 0s deletion_mode: filter-and-delete compactor: working_directory: /var/loki/compactor retention_enabled: true delete_request_store: gcs://bucket_for_delete_requests delete_request_cancel_period: 24h delete_max_interval: 24h三种删除模式deletion_mode怎么选deletion_mode决定删除请求对查询层和存储层各产生什么效果模式查询层行为存储层行为典型场景disabled照常返回不删除未授权租户删除 API 直接返回403filter-only过滤掉匹配行不删除数据仍在存储里先观察删除范围或只做逻辑擦除filter-and-delete过滤掉匹配行从存储中物理移除默认合规删除数据必须真正消失决策建议✅ 先用filter-only跑一轮在查询里确认命中范围符合预期再切到filter-and-delete落地物理删除不需要删除能力的租户用disabled锁死。配置拼写错误比如filteranddelete会导致请求解析失败注意连字符。动手Loki compactor 删除 API 实操提交、跟踪、取消三个端点都挂在 compactor 上且仅在 retention 启用时存在。多租户环境用X-Scope-OrgID请求头指定租户完整参数见官方 HTTP API 文档。提交删除请求的 curl 写法通过POST /loki/api/v1/delete创建删除请求。参数要点query必填LogQL 流选择器可带行过滤器需做 URL 编码start/end必填Unix 秒或 RFC3339 两种格式都行不允许删除未来时间且start必须小于endmax_interval可选单个请求允许的最大跨度不能超过delete_max_interval合法单位s、m、h下面这条命令提交一个删除请求-g参数用于关掉 curl 对花括号的大括号展开curl -g -X POST \ http://loki-compactor:3100/loki/api/v1/delete?query{clusterprod}start1704067200end1704153600 \ -H X-Scope-OrgID: tenant1成功返回204 No Content响应头X-Delete-Request-ID里带着请求 ID取消时要用。表达式非法比如正则写错会在提交时立刻拿到 400不会拖到执行期才暴露问题。跟踪查询删除请求状态GET /loki/api/v1/delete按创建时间排序返回该租户的全部删除请求支持两个可选过滤参数for_querytime_filteringtrue只返回与查询时过滤相关的那部分startend只返回与给定时间范围有交集的请求这条命令列出指定时间范围内的所有删除请求curl -X GET \ http://loki-compactor:3100/loki/api/v1/delete?start1704067200end1704153600 \ -H X-Scope-OrgID: tenant1被拆分过的同一请求会以一条记录合并展示状态字段取Received、Processed或N% Complete三种之一数字就是已完成子请求的占比。取消Loki 删除请求取消方法DELETE /loki/api/v1/delete?request_idID用于撤回请求取消期cancellation period即提交后到真正删除前的保护窗口由delete_request_cancel_period控制默认24h内随时可撤请求已被处理或已完成时默认返回 400 拒绝forcetrue的适用场景请求已经开始处理或已超过取消期。注意强制撤回后已删掉的那部分数据不会恢复请求状态仍会显示为已处理带强制参数的取消命令curl -X DELETE \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_IDforcetrue \ -H X-Scope-OrgID: tenant1成功同样返回204。撤掉之后请求会从存储中移除GET结果里不再出现。缓存失效端点删除之后查询结果缓存可能还留着旧数据Loki 用缓存代数cache generation number用来判断查询结果缓存是否过期解决GET /loki/api/v1/cache/generation_numbers查看租户当前代数POST /loki/api/v1/cache/generation_numbers/increase手动递增让该租户的查询缓存全部失效回放历史数据这类场景会用到删除完成后代数会自动递增无需手动干预请求在背后经历了什么提交只是记了一笔账真正的执行是一条五步流水线周期扫描compactor 在每个 retention 周期apply_retention_interval默认与压缩周期一致并额外加上不超过 10 分钟的抖动避免和压缩撞车扫一遍所有未处理的删除请求取消期过滤只有创建时间已超过delete_request_cancel_period默认 24h的请求才进入删除阶段保护窗口在这里兜底批量执行每个周期最多处理delete_batch_size默认 70个请求防止一个大请求拖死整条队列chunk 重建写回filter-and-delete模式下把相关 chunk 读出来、剔掉匹配行、重建后再传回对象存储并更新索引这一步之前还有一层retention_delete_delay默认 2h缓冲缓存失效处理完成后自动递增缓存代数后续查询不会再命中已删数据的旧缓存分片机制只作用于带行过滤器的请求每个分片最多覆盖delete_max_interval默认 24h相邻子请求之间刻意保留少量时间重叠避免毫秒级边界上的日志漏删不带行过滤器的请求原样执行不拆分。存储层与迁移删除请求存在哪里删除请求本身也要持久化它由两个不同维度的配置共同决定delete_request_store对象存储位置即请求数据文件所在的桶与路径前缀默认index/delete_request_store_db_type本地数据库引擎默认boltdb可换成sqlite想把引擎从 boltdb 迁到 sqlite 时先给备份库开双写请求同时落进旧的 boltdb 存储迁移期间一条都不丢切换完成后把备份配置去掉。备份库目前只支持 boltdb。迁移期的三行配置compactor: delete_request_store_db_type: sqlite backup_delete_request_store_db_type: boltdb两种引擎的实现分别放在 delete_requests_db_boltdb.go 和 delete_requests_db_sqlite.go配套测试齐全想深入细节可以直接读源码。避坑清单⚠️对象存储先开版本控制。retention 或保留期一旦配错版本历史是你唯一能回头的路。⚠️先 filter-only 试跑再物理删除。在查询层确认命中范围无误再切filter-and-delete避免一上来就删错。⚠️带行过滤器的删除非常吃 CPU 和 IO——读 chunk、剔行、重写、回传一步不少。批量删大量数据时按compactor 水平扩展文档把负载摊到多个 compactor 实例上。⚠️用max_interval控制单请求跨度。别把一个请求跨好几天执行时间会拖到失控。⚠️盯住loki_compactor_deletion_*指标。请求积压、删除行数、失败数都在这组指标里发现异常及时扩容或拆请求。把retention_enabled、delete_request_store、deletion_mode三件套配齐之后Grafana Loki 的日志删除就是一个完全可预期的流程提交请求、享受保护窗口、由 compactor 在后台分片并批量执行、最后在查询层验证干净。真正不可逆的只有物理删除这一步——开版本控制、先 filter-only 试跑、盯紧指标这三件事做到位这项能力就可以放心用了。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
