Grafana Loki 日志删除完整实操指南从开启到取消请求一次讲清避坑点【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki凌晨的告警电话响了一批含用户隐私的明文数据被误写进了生产日志。你清楚光把查询层挡掉没用数据还躺在对象存储里必须真正抹掉。日志到底能不能删Grafana Loki 的答案是可以——日志条目删除功能支持按指定流、时间窗口删除还能用可选的 LogQL 行过滤器精确到具体某几行统一由 compactor 组件承载执行。能删什么Loki 日志条目删除的能力边界Loki 只能删除指定流 指定时间窗口内的日志。删除请求携带一个 LogQL 流选择器如{clusterprod}可选地追加行过滤器如| ERROR来框定要抹掉的具体行。行为模式由deletion_mode决定位于limits_config可按租户在运行时配置中覆盖共三种取值取值查询行为存储行为disabled删除 API 返回403 Forbidden不删除filter-only查询时过滤掉匹配删除请求的日志行数据仍留在存储中filter-and-delete查询时过滤且从存储中物理删除真正移除默认值 只想拥有删除能力、又不想强制执行数据保留期时把retention_period设为0s即可。三步开启 Grafana Loki 日志删除删除功能建立在 compactor 的 retention 机制之上三个条件缺一不可第 1 步启用 retention设置retention_enabled: true。第 2 步配置delete_request_store指定存放删除请求的对象存储桶。启用 retention 后该项为必填漏配会让 compactor 启动校验直接失败。第 3 步确认deletion_mode。默认值就是filter-and-delete所以前两步完成后删除功能对所有租户默认生效一般无需改动。最小可用配置limits_config: retention_period: 0s # 不强制保留期仅开启删除能力 deletion_mode: filter-and-delete compactor: working_directory: /var/loki/compactor retention_enabled: true delete_request_store: gcs://delete-requests-bucket⚠️强烈建议在对象存储上开启版本控制versioning——否则 retention 配置误操作或删错请求数据将无法找回。Loki 删除请求 API提交、查询与取消三个动作都走 compactor 的/loki/api/v1/delete端点多租户需带X-Scope-OrgID请求头。提交删除query传 LogQL 表达式start/end同时支持 Unix 秒与 RFC3339 格式。注意两个校验不允许删除未来时间的数据且 start 必须小于 end否则返回 400成功返回204删除请求 ID 在响应头X-Delete-Request-ID中。curl -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7Dstart1704067200end1704153600带行过滤器的请求会被自动分片成多个子请求每个子请求覆盖不超过delete_max_interval默认 24h的时间跨度你可以用max_interval参数把分片调得更小最小 1s且不能超过全局上限或待删窗口本身子请求之间刻意保留少量时间重叠防止边界漏删。不带过滤器的请求不分片。查询进度GET 返回该租户全部删除请求JSON 数组按创建时间排序可选start/end做时间重叠过滤for_querytime_filteringtrue只返回与查询过滤相关的请求。被分片的同一条请求会合并展示状态显示为Received、Processed或N% Complete。取消请求默认24 小时保护窗口由delete_request_cancel_period控制内可直接取消请求一旦进入处理或已完成需附加forcetrue强制取消curl -X PUT -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_IDforcetrue为什么提交后数据不会立刻消失删除请求提交后不会马上生效这是一条刻意的时间线保护期默认 24h给你留出取消窗口只有创建时间超过delete_request_cancel_period的请求才会进入删除阶段周期扫描compactor 在每个 retention 周期apply_retention_interval默认为 0 时与压缩周期一致并自动加抖动检查未处理的删除请求批量执行每个周期最多处理delete_batch_size默认 70个请求由retention_delete_worker_count默认 150个工作协程执行chunk 重建写回chunk 是 Loki 存放日志的数据块。删除行时 compactor 需把相关 chunk 读出、剔除匹配行、重写后回传对象存储并更新索引另有retention_delete_delay默认 2h缓冲完成后自动递增缓存代数保证查询不会命中已删数据的旧缓存。删除请求存哪里boltdb 与 sqlite 的迁移删除请求本身持久化在本地数据库中引擎由delete_request_store_db_type指定默认boltdb可切换为sqlite。注意它与delete_request_store是两个维度——前者是本地数据库引擎后者是删除请求数据文件存放的对象存储位置。跨引擎迁移时把backup_delete_request_store_db_type设为boltdb删除请求会双写到备份库迁移期间一条请求都不丢当前备份库仅支持 boltdb。Loki 日志删除生产避坑指南带行过滤器的删除是 compactor 最耗资源的操作之一每个相关 chunk 都要读出来重建再写回CPU 与 IO 双高。大批量、多租户场景建议参考 compactor 横向扩展方案把删除工作分散到多个 compactor 实例上。先观察后落地先把租户切成filter-only用真实查询核对删除范围确认无误再切回filter-and-delete执行物理删除。盯住指标loki_compactor_deletion_*指标会持续上报接收、处理与失败的删除请求积压上涨或失败突增是第一预警信号。✅ 用max_interval控制单个带过滤器的请求跨度别把几天的数据塞进一个请求里慢慢磨。一句话总结与延伸阅读Loki 日志删除 开 retention 配删除请求桶 用deletion_mode定模式请求经 REST API 提交后交给保护窗口和 compactor 的周期扫描去完成剩下的事。延伸阅读仓库内相对路径删除功能源码pkg/compactor/deletion/compactor 配置与校验逻辑pkg/compactor/config.go删除 API 参考文档docs/sources/reference/loki-http-api.mdcompactor 横向扩展docs/sources/operations/storage/compactor-horizontal-scaling.md【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考