Grafana Loki 日志删除实操从提交请求到数据真正被删掉【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki想象一下这样的场景某租户把包含支付卡号的日志写进了 Loki合规要求必须在 72 小时内把这些行从存储里清掉。Grafana Loki 的日志条目删除Log Entry Deletion就是为此设计的——你提交一个带流选择器、时间窗口、可选行过滤器的删除请求等取消期过后数据才真正从对象存储里消失。下面按先跑通、再会查、最后敢删的顺序讲清楚。 30 秒心智模型删除是先记账、再执行的两段式操作删除是异步任务不是同步动作。提交请求只产生一条持久化的删除记录真正的数据移除由 compactor 周期性执行中间隔着两段缓冲时间见后文。取消期就是你提交后的后悔窗口。在delete_request_cancel_period默认24h内请求随时可以撤销超过窗口就基本不可逆了。删除记录本身会被持久化所以即使是只过滤不删的模式查询路径也会按它实时过滤结果——提交即对查询生效。三种模式决定最终行为disabled禁止删除API 拒绝、filter-only只过滤不删、filter-and-delete过滤并从存储移除默认值。执行者只有一个角色compactor。微服务模式里它是独立组件负责 retention 与删除的整套工作一句话总结API 负责登记compactor 负责执行取消期是你的反悔时间。 上手路径三处配置 一次成功调用这节解决最小要改哪些东西才能跑起来的问题。删除能力同时依赖三个开关缺一不可compactor 侧retention_enabled: true——删除 API 端点只在这个开关为true时才注册否则所有请求直接返回400 Retention is not enabledcompactor 侧delete_request_store必填——否则启动校验直接失败报错compactor.delete-request-store should be configured when retention is enabled见 pkg/compactor/config.go 的Validate()租户的deletion_mode不是disabled——它是limits_config中的全局加按租户设置默认filter-and-delete所以满足前两条后所有租户开箱可用也可在运行时配置文件中按租户覆盖。最小可用配置注释说明每行为什么limits_config: retention_period: 0s # 只要删除能力、不强制按保留期清理就设为 0s deletion_mode: filter-and-delete # 全局默认想先观察命中范围可先改 filter-only compactor: working_directory: /var/loki/compactor retention_enabled: true # 不开这个删除端点根本不存在 delete_request_store: gcs://bucket_for_delete_requests # 删除记录的存放位置按你的对象存储类型改 delete_request_store_db_type: boltdb # 本地请求数据库引擎默认 boltdb可换 sqlite delete_request_cancel_period: 24h # 后悔窗口源码注释建议至少 24h delete_max_interval: 24h # 带行过滤器的单个分片最大跨度配置生效后提交一条删除请求做冒烟验证curl -i -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7Dstart1704067200end1704153600参数逐个说queryLogQL 流选择器如{clusterprod}可追加行过滤器| ERROR。表达式会在提交时就解析校验regex 写错、ip()模式非法等直接400不会拖到执行期才炸。start/end起始与结束时间Unix 秒必须是 10 位或 RFC3339 格式。两个硬校验end不能指向未来deletes in the future are not allowedstart必须严格小于endstart time cant be greater than or equal to end time。多租户用X-Scope-OrgID头标识请求按租户隔离。成功的样子204 No Content响应头X-Delete-Request-ID里就是删除请求 ID请收好后续查询和取消都靠它。失败的样子各种400加上明确的错误文案query not set、start time not set、invalid start time: require unix seconds or RFC3339 format等全部在提交阶段拦截不会产生半成品请求。 操作手册提交 → 查询 → 取消这节把日常会用到的端点按动作流串起来每条都给出命令、关键参数和成败判据。提交带行过滤器时记得控制分片大小curl -i -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7D%20%7C%3D%20%22ERROR%22start1704067200end1704681600max_interval12hmax_interval是唯一的可选参数语义是单个子请求最多覆盖多长约束触发的错误最小1s单位仅s、m、hinvalid max_interval: valid time units are s, m, h不能超过delete_max_intervalmax_interval cant be greater than 24h0m0s不能超过本次要删的窗口本身max_interval cant be greater than the interval to be deleted (...)查询看状态、看进度curl -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete返回该租户的删除请求 JSON 数组按创建时间升序。两个可选参数for_querytime_filteringtrue只返回与查询时过滤相关的请求startend时间重叠过滤只返回与给定区间有交集的请求。被拆分过的同一请求的多个子请求会被合并成一条展示状态按完成比例呈现Received未开始、N% Complete部分完成、Processed全部完成。验证生效最直接的方式就是轮询这个接口等状态从Received走到Processed若是filter-only模式还可以直接对查询做回归确认匹配行已不可见。取消窗口内随便撤窗口外要 forcecurl -i -X PUT -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_ID成败判据一览场景响应取消成功204 No ContentID 不存在404 could not find delete request with given id请求已在处理中或已完成Processed400 deletion of request which is in process or already processed is not allowed已超过取消期400 Cancellation of partially completed delete request or delete request past the deadline of 24h0m0s since its creation is not allowed. To force, use the ?force query parameter最后这种想强行撤销追加forcetrue即可curl -X PUT -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_IDforcetrue辅助手动使查询缓存失效删除完成后缓存代数会自动更新保证查询不会命中已删数据的缓存。但如果是回放历史数据等其他场景导致查询结果不一致可以手动递增某租户的缓存代数GET /loki/api/v1/cache_generation_number查看POST同一端点递增成功返回204该租户的查询结果缓存随即失效。⚙️ 原理与边界只讲影响你决策的部分这节不展开源码只回答什么情况下这些机制会咬到你。什么时候数据才真正消失提交请求 ≠ 删除发生。时序是取消期delete_request_cancel_period默认24h→ compactor 在每个 retention 周期扫描未处理且已过取消期的请求 → 每周期最多处理delete_batch_size默认70个 → chunk 重建并写回对象存储。apply_retention_interval设为0时与 compaction 周期默认10m一致并自动加上最多10m不超过其一半的抖动避免撞车。filter-and-delete模式下涉及删除的 chunk 需要读出来、剔除匹配行、重写再写回这是 CPU 与 IO 最重的操作需要大批量、多租户删带过滤器的数据时考虑横向扩展 compactor把删除工作分到多个实例。什么时候分片机制会影响你只有带行过滤器的请求会被拆分超过delete_max_interval默认24h的窗口会被切成多个不超过该跨度的子请求不带行过滤器的请求永远不拆。分片之间刻意保留少量时间重叠而非精确衔接避免边界 1ms 的缝隙漏删。你要关心的只是删除窗口很长且带行过滤器时用max_interval把单片压小避免单个请求执行时间过长。什么时候会碰到请求存储迁移删除记录存两份维度delete_request_store是对象存储位置放数据文件delete_request_store_db_type是本地数据库引擎boltdb默认或sqlite。从一种引擎迁到另一种时设backup_delete_request_store_db_type: boltdb让请求双写备份库迁移期间不丢请求——当前备份库仅支持 boltdb。索引存储侧的约束TSDB 索引完整支持删除BoltDB Shipper 索引虽也支持但将在 Loki 4.0 移除新部署直接用 TSDB。 避坑清单⚠️启用 retention 前先在对象存储上开启版本控制。retention 配错会连带删数据没有版本控制就没有回滚。对策开启 versioning 是启用retention_enabled: true的前置动作不是可选项只想用删除能力、不想强制保留期把retention_period设0s。⚠️filter-only是免费的试错通道。先切到filter-only提交同样的请求用查询验证实际命中范围确认无误再改回filter-and-delete落地物理删除。对策同一请求在两种模式下都会持久化观察期不丢数据。⚠️取消窗口过后就没有第二次机会了。默认24h且已进入处理中的请求默认不可取消forcetrue也只能用于部分完成的请求。对策把delete_request_cancel_period按合规节奏调长提交后立刻用 GET 接口核对流、时间窗口、行过滤器三要素再等待。⚠️deletion_mode拼错不会静默降级而是直接报错。未知值返回unknown deletion mode: must be one of disabled|filter-only|filter-and-delete请求校验阶段就失败。对策上线前用一次400请求冒烟或检查运行时配置里租户覆盖值的拼写。⚠️带行过滤器的删除是 compactor 上最重的活之一。每个相关 chunk 都要读出、剔除、重写、回传积压会拖慢整个 retention 周期。对策监控loki_compactor_deletion_*指标选中 chunk 数、已删行数、已处理请求数、失败数观察积压与失败需要时按官方横向扩展方案把 compactor 扩成多实例分摊删除负载。 快速参考配置项 / 端点默认值作用compactor.retention_enabledfalse总开关true才注册删除端点compactor.delete_request_store空启用 retention 时必填删除记录的对象存储位置compactor.delete_request_store_key_prefixindex/记录在桶中的路径前缀compactor.delete_request_store_db_typeboltdb本地请求数据库引擎boltdb/sqlitecompactor.delete_request_cancel_period24h后悔窗口过后才执行删除compactor.delete_max_interval24h带行过滤器请求的单分片最大跨度compactor.delete_batch_size70每 retention 周期最多处理的请求数compactor.retention_delete_delay2hchunk 真正被删除前的额外缓冲compactor.retention_delete_worker_count150删除 chunk 的工作协程数limits_config.deletion_modefilter-and-delete全局/按租户模式disabled时端点返回403语义的拒绝POST /loki/api/v1/delete—提交删除请求204X-Delete-Request-IDGET /loki/api/v1/delete—列出请求支持for_querytime_filtering、start/endPUT /loki/api/v1/delete?request_id...—取消请求超期需forcetrue204成功删除能力 retention_enableddelete_request_store 非disabled的deletion_mode三要素齐备即对租户生效。记住两段缓冲——取消期与retention_delete_delay——就是提交与真删之间的距离。把filter-only当演练、把取消期当刹车、把 compactor 指标当仪表盘这套强操作能力就能安全地用在生产上。输出文章【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Grafana Loki 日志删除实操：从提交请求到数据真正被删掉
Grafana Loki 日志删除实操从提交请求到数据真正被删掉【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki想象一下这样的场景某租户把包含支付卡号的日志写进了 Loki合规要求必须在 72 小时内把这些行从存储里清掉。Grafana Loki 的日志条目删除Log Entry Deletion就是为此设计的——你提交一个带流选择器、时间窗口、可选行过滤器的删除请求等取消期过后数据才真正从对象存储里消失。下面按先跑通、再会查、最后敢删的顺序讲清楚。 30 秒心智模型删除是先记账、再执行的两段式操作删除是异步任务不是同步动作。提交请求只产生一条持久化的删除记录真正的数据移除由 compactor 周期性执行中间隔着两段缓冲时间见后文。取消期就是你提交后的后悔窗口。在delete_request_cancel_period默认24h内请求随时可以撤销超过窗口就基本不可逆了。删除记录本身会被持久化所以即使是只过滤不删的模式查询路径也会按它实时过滤结果——提交即对查询生效。三种模式决定最终行为disabled禁止删除API 拒绝、filter-only只过滤不删、filter-and-delete过滤并从存储移除默认值。执行者只有一个角色compactor。微服务模式里它是独立组件负责 retention 与删除的整套工作一句话总结API 负责登记compactor 负责执行取消期是你的反悔时间。 上手路径三处配置 一次成功调用这节解决最小要改哪些东西才能跑起来的问题。删除能力同时依赖三个开关缺一不可compactor 侧retention_enabled: true——删除 API 端点只在这个开关为true时才注册否则所有请求直接返回400 Retention is not enabledcompactor 侧delete_request_store必填——否则启动校验直接失败报错compactor.delete-request-store should be configured when retention is enabled见 pkg/compactor/config.go 的Validate()租户的deletion_mode不是disabled——它是limits_config中的全局加按租户设置默认filter-and-delete所以满足前两条后所有租户开箱可用也可在运行时配置文件中按租户覆盖。最小可用配置注释说明每行为什么limits_config: retention_period: 0s # 只要删除能力、不强制按保留期清理就设为 0s deletion_mode: filter-and-delete # 全局默认想先观察命中范围可先改 filter-only compactor: working_directory: /var/loki/compactor retention_enabled: true # 不开这个删除端点根本不存在 delete_request_store: gcs://bucket_for_delete_requests # 删除记录的存放位置按你的对象存储类型改 delete_request_store_db_type: boltdb # 本地请求数据库引擎默认 boltdb可换 sqlite delete_request_cancel_period: 24h # 后悔窗口源码注释建议至少 24h delete_max_interval: 24h # 带行过滤器的单个分片最大跨度配置生效后提交一条删除请求做冒烟验证curl -i -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7Dstart1704067200end1704153600参数逐个说queryLogQL 流选择器如{clusterprod}可追加行过滤器| ERROR。表达式会在提交时就解析校验regex 写错、ip()模式非法等直接400不会拖到执行期才炸。start/end起始与结束时间Unix 秒必须是 10 位或 RFC3339 格式。两个硬校验end不能指向未来deletes in the future are not allowedstart必须严格小于endstart time cant be greater than or equal to end time。多租户用X-Scope-OrgID头标识请求按租户隔离。成功的样子204 No Content响应头X-Delete-Request-ID里就是删除请求 ID请收好后续查询和取消都靠它。失败的样子各种400加上明确的错误文案query not set、start time not set、invalid start time: require unix seconds or RFC3339 format等全部在提交阶段拦截不会产生半成品请求。 操作手册提交 → 查询 → 取消这节把日常会用到的端点按动作流串起来每条都给出命令、关键参数和成败判据。提交带行过滤器时记得控制分片大小curl -i -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7D%20%7C%3D%20%22ERROR%22start1704067200end1704681600max_interval12hmax_interval是唯一的可选参数语义是单个子请求最多覆盖多长约束触发的错误最小1s单位仅s、m、hinvalid max_interval: valid time units are s, m, h不能超过delete_max_intervalmax_interval cant be greater than 24h0m0s不能超过本次要删的窗口本身max_interval cant be greater than the interval to be deleted (...)查询看状态、看进度curl -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete返回该租户的删除请求 JSON 数组按创建时间升序。两个可选参数for_querytime_filteringtrue只返回与查询时过滤相关的请求startend时间重叠过滤只返回与给定区间有交集的请求。被拆分过的同一请求的多个子请求会被合并成一条展示状态按完成比例呈现Received未开始、N% Complete部分完成、Processed全部完成。验证生效最直接的方式就是轮询这个接口等状态从Received走到Processed若是filter-only模式还可以直接对查询做回归确认匹配行已不可见。取消窗口内随便撤窗口外要 forcecurl -i -X PUT -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_ID成败判据一览场景响应取消成功204 No ContentID 不存在404 could not find delete request with given id请求已在处理中或已完成Processed400 deletion of request which is in process or already processed is not allowed已超过取消期400 Cancellation of partially completed delete request or delete request past the deadline of 24h0m0s since its creation is not allowed. To force, use the ?force query parameter最后这种想强行撤销追加forcetrue即可curl -X PUT -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_IDforcetrue辅助手动使查询缓存失效删除完成后缓存代数会自动更新保证查询不会命中已删数据的缓存。但如果是回放历史数据等其他场景导致查询结果不一致可以手动递增某租户的缓存代数GET /loki/api/v1/cache_generation_number查看POST同一端点递增成功返回204该租户的查询结果缓存随即失效。⚙️ 原理与边界只讲影响你决策的部分这节不展开源码只回答什么情况下这些机制会咬到你。什么时候数据才真正消失提交请求 ≠ 删除发生。时序是取消期delete_request_cancel_period默认24h→ compactor 在每个 retention 周期扫描未处理且已过取消期的请求 → 每周期最多处理delete_batch_size默认70个 → chunk 重建并写回对象存储。apply_retention_interval设为0时与 compaction 周期默认10m一致并自动加上最多10m不超过其一半的抖动避免撞车。filter-and-delete模式下涉及删除的 chunk 需要读出来、剔除匹配行、重写再写回这是 CPU 与 IO 最重的操作需要大批量、多租户删带过滤器的数据时考虑横向扩展 compactor把删除工作分到多个实例。什么时候分片机制会影响你只有带行过滤器的请求会被拆分超过delete_max_interval默认24h的窗口会被切成多个不超过该跨度的子请求不带行过滤器的请求永远不拆。分片之间刻意保留少量时间重叠而非精确衔接避免边界 1ms 的缝隙漏删。你要关心的只是删除窗口很长且带行过滤器时用max_interval把单片压小避免单个请求执行时间过长。什么时候会碰到请求存储迁移删除记录存两份维度delete_request_store是对象存储位置放数据文件delete_request_store_db_type是本地数据库引擎boltdb默认或sqlite。从一种引擎迁到另一种时设backup_delete_request_store_db_type: boltdb让请求双写备份库迁移期间不丢请求——当前备份库仅支持 boltdb。索引存储侧的约束TSDB 索引完整支持删除BoltDB Shipper 索引虽也支持但将在 Loki 4.0 移除新部署直接用 TSDB。 避坑清单⚠️启用 retention 前先在对象存储上开启版本控制。retention 配错会连带删数据没有版本控制就没有回滚。对策开启 versioning 是启用retention_enabled: true的前置动作不是可选项只想用删除能力、不想强制保留期把retention_period设0s。⚠️filter-only是免费的试错通道。先切到filter-only提交同样的请求用查询验证实际命中范围确认无误再改回filter-and-delete落地物理删除。对策同一请求在两种模式下都会持久化观察期不丢数据。⚠️取消窗口过后就没有第二次机会了。默认24h且已进入处理中的请求默认不可取消forcetrue也只能用于部分完成的请求。对策把delete_request_cancel_period按合规节奏调长提交后立刻用 GET 接口核对流、时间窗口、行过滤器三要素再等待。⚠️deletion_mode拼错不会静默降级而是直接报错。未知值返回unknown deletion mode: must be one of disabled|filter-only|filter-and-delete请求校验阶段就失败。对策上线前用一次400请求冒烟或检查运行时配置里租户覆盖值的拼写。⚠️带行过滤器的删除是 compactor 上最重的活之一。每个相关 chunk 都要读出、剔除、重写、回传积压会拖慢整个 retention 周期。对策监控loki_compactor_deletion_*指标选中 chunk 数、已删行数、已处理请求数、失败数观察积压与失败需要时按官方横向扩展方案把 compactor 扩成多实例分摊删除负载。 快速参考配置项 / 端点默认值作用compactor.retention_enabledfalse总开关true才注册删除端点compactor.delete_request_store空启用 retention 时必填删除记录的对象存储位置compactor.delete_request_store_key_prefixindex/记录在桶中的路径前缀compactor.delete_request_store_db_typeboltdb本地请求数据库引擎boltdb/sqlitecompactor.delete_request_cancel_period24h后悔窗口过后才执行删除compactor.delete_max_interval24h带行过滤器请求的单分片最大跨度compactor.delete_batch_size70每 retention 周期最多处理的请求数compactor.retention_delete_delay2hchunk 真正被删除前的额外缓冲compactor.retention_delete_worker_count150删除 chunk 的工作协程数limits_config.deletion_modefilter-and-delete全局/按租户模式disabled时端点返回403语义的拒绝POST /loki/api/v1/delete—提交删除请求204X-Delete-Request-IDGET /loki/api/v1/delete—列出请求支持for_querytime_filtering、start/endPUT /loki/api/v1/delete?request_id...—取消请求超期需forcetrue204成功删除能力 retention_enableddelete_request_store 非disabled的deletion_mode三要素齐备即对租户生效。记住两段缓冲——取消期与retention_delete_delay——就是提交与真删之间的距离。把filter-only当演练、把取消期当刹车、把 compactor 指标当仪表盘这套强操作能力就能安全地用在生产上。输出文章【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考