Grafana Loki 日志删除实战指南从最小配置到取消一条发错的删除请求【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiGrafana Loki 支持按流、时间窗口和可选行过滤器删除日志条目删除请求由 compactor 承载提交后先进入可反悔的取消期之后数据才从对象存储中物理移除。这是一份 Loki 日志删除的落地指南。什么情况下你真正需要删日志日志只增不删的假设在三种场景下会失效合规要求GDPR 等法规要求删除特定主体关联的日志不再展示不够必须让数据物理消失隐私数据误写密钥、token、个人信息被打进了日志留在对象存储里就是长期风险容量回收某批测试数据、某个事故期间的爆量日志占据了可观的存储费用。但删在 Loki 里不是像rm那样直接擦掉一块数据。Loki 把日志按流stream打包成一个个chunk压缩后的日志块是对象存储的最小读写单位索引只记录哪个流的数据在哪些 chunk 里。因此带行过滤器的物理删除本质上是把受影响的 chunk 读出来、剔除匹配行、重建压缩块、再写回对象存储并更新索引而不带行过滤器的删除整条流的时间窗口则可以直接废弃整块 chunk。另外先明确一个索引前提日志条目删除在TSDB 索引下完整支持旧的 BoltDB-Shipper 索引也能用但它计划在 Loki 4.0 移除新集群请直接用 TSDB。快速上手三个前置条件加一份最小配置删除能力不默认开启三个条件缺一不可打开 retention 开关compactor.retention_enabled: true。删除 API 端点只有在它开启时才注册否则所有请求都会得到 400Retention is not enabled见 pkg/loki/modules.go 中的端点注册逻辑。配置删除请求存储桶delete_request_store必须非空。开启 retention 却没填它compactor 启动校验会直接报错退出pkg/compactor/config.go 中Validate()。租户的deletion_mode不是disabled默认值就是filter-and-delete所以前两条满足后删除对所有租户天然生效。⚠️开 retention 前先给对象存储桶打开版本控制versioning。retention 和删除都是不可逆的重操作桶的版本历史是你唯一的后悔药。如果只想开删除能力、并不打算按保留期清理数据把limits_config.retention_period设为0s即可。一份最小可用配置limits_config: retention_period: 0s # 不强制执行 retention仅开启删除能力 deletion_mode: filter-and-delete compactor: working_directory: /var/loki/compactor retention_enabled: true delete_request_store: gcs://your-bucket/delete-requests # 换成你的对象存储 delete_request_store_db_type: boltdb delete_request_cancel_period: 24h delete_max_interval: 24h与删除直接相关的 compactor 配置项及默认值源码见 pkg/compactor/config.go配置项默认值作用retention_enabledfalse删除 API 的总开关delete_request_store空启用 retention 后必填存放删除请求的对象存储桶delete_request_store_key_prefixindex/桶内路径前缀delete_request_store_db_typeboltdb本地数据库引擎可选sqlitebackup_delete_request_store_db_type空迁移用的备份库当前仅支持 boltdbdelete_request_cancel_period24h取消期请求超过该时长后数据才会被真正删除delete_max_interval24h带行过滤器的删除请求分片跨度上限delete_batch_size70每个周期最多处理的删除请求数retention_delete_delay2h取消期之后、chunk 真正删除前的额外缓冲retention_delete_worker_count150删除 chunk 的并发协程数apply_retention_interval0sretention 生效周期为 0 时自动对齐 compaction 周期并加最多 10 分钟抖动避免两者抢同一时刻模式选型deletion_mode 三种取值怎么选deletion_mode定义在limits_config中支持全局默认值加按租户覆盖覆盖写在运行时配置文件里取值来自 pkg/validation/limits.go。它回答一个问题匹配删除请求的日志是看不见还是不存在按你的诉求对号入座只要看不见物理数据还要留着例如法务要求隐藏但你自己想保留取证副本→ 选filter-only。查询路径会按需过滤掉匹配行对象存储里的 chunk 原封不动。必须物理消失GDPR 类合规→ 选filter-and-delete默认值。查询时过滤同时 compactor 会把数据从存储中移除。共享集群里不想让某个租户碰删除→ 对该租户覆盖为disabled。此时它的删除 API 请求会被拒绝validDeletionLimit检查不通过见 pkg/compactor/deletion/util.go。两个容易踩的点拼写错误会被拒绝。ParseMode只认disabled、filter-only、filter-and-delete三个值写错一个字母配置校验直接失败pkg/compactor/deletionmode/mode.go。端点注册与 retention 强绑定与 deletion_mode 无关。retention_enabled为 false 时端点压根不存在handler 为 nil任何租户访问都得到 400。先开 retention再用deletion_mode做租户级收放这是正确的控制顺序。实操提交、查询、取消一条删除请求删除端点挂在 compactor 上路径统一为/loki/api/v1/deletePOST 提交、GET 查询、DELETE 取消注意取消用的是 HTTP DELETE 方法。所有操作都需要租户头X-Scope-OrgID。提交删除请求。参数规则来自 pkg/compactor/deletion/request_handler.goquery必填LogQL 流选择器可带行过滤器如{clusterprod} | ERROR。提交时就会完整解析并构建 pipeline非法的正则、写错的ip()模式会当场返回 400而不是留到执行期爆炸start/end必填Unix 秒必须恰好 10 位数字或 RFC3339 格式。两条硬规则不允许删除未来时间deletes in the future are not allowed且 start 必须严格小于 endmax_interval可选请求更细的分片最小1s单位只认s/m/h不能大于delete_max_interval也不能大于待删时间窗口本身。curl -X POST -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?query%7Bcluster%3D%22prod%22%7Dstart1704067200end1704153600成功返回204 No Content响应头X-Delete-Request-ID就是这条删除请求的 ID取消时要用到。查询删除请求。返回该租户全部请求的 JSON 数组按创建时间排序内部字段UserID、SequenceNum会被抹掉。curl -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete # 只看在查询时参与过滤的请求 curl -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?for_querytime_filteringtrue # 按时间重叠过滤start/end 同样支持 Unix 秒或 RFC3339 curl -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?start1704067200end1704153600被分片的大请求在列表里会合并回一条展示状态按已完成子请求比例渲染为Received、N% Complete或Processed合并逻辑mergeDeletes。取消一条发错的删除请求。常规取消只在取消期内、且请求还没开始处理时有效curl -X DELETE -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_ID三种会被 400 挡回的情况请求 ID 不存在404、状态已是Processed、请求已部分完成或创建时间超过delete_request_cancel_period默认 24h。后两种可以加forcetrue强制取消curl -X DELETE -H X-Scope-OrgID: tenant1 \ http://loki-compactor:3100/loki/api/v1/delete?request_idREQUEST_IDforcetrue另有两个缓存辅助端点与删除联动GET /loki/api/v1/cache/generation_numbers查租户的缓存代数POST /loki/api/v1/cache/generation_numbers/increase手动递增代数、令该租户的查询结果缓存失效例如回放历史数据后。删除处理完成时代数会自动递增保证查询不会命中已删数据的旧缓存。幕后机制一条删除请求提交后发生了什么时间线比直觉中慢很多这是刻意的提交后先躺平。请求进入存储状态Received。只有当请求年龄超过delete_request_cancel_period默认 24h它才会进入实际删除阶段——这 24 小时就是给你留的取消窗口。compactor 周期扫描。每个 retention 周期apply_retention_interval默认与 compaction 周期一致并带抖动检查未处理请求每个周期最多处理delete_batch_size默认 70条。分片只针对带行过滤器的请求。流选择器本身不带过滤器时整个时间窗口就是一条请求不拆分。带行过滤器时buildRequests会把它切成每段不超过delete_max_interval的子请求且相邻子请求刻意保留少量时间重叠而不是严丝合缝——因为端点是闭区间语义精确衔接会在边界留 1ms 缝隙漏删日志。重建与写回。filter-and-delete模式下涉及删除的 chunk 会被读出、剔除匹配行、重写压缩块、上传回对象存储并更新索引带行过滤器的删除由删除清单deletion manifestdeletion_manifest_builder.go驱动。整个动作还要再等retention_delete_delay默认 2h的缓冲。横向扩展。horizontal_scaling_mode支持 main/worker 分工删除作业经 jobqueue 分发给 workerpkg/compactor/deletion/job_runner.go。执行进度由 delete_requests_manager.go 中的DeleteRequestsManager持续推进指标定义在 pkg/compactor/deletion/metrics.go包括deleteRequestsReceivedTotal、deleteRequestsProcessedTotal、deletedLinesTotal、deletionFailures等前缀loki_compactor_是观察积压和失败的第一现场。⚠️带行过滤器的删除是 compactor 最耗资源的操作之一每个相关 chunk 都要读出来、剔除匹配行、再重写回对象存储CPU 和 IO 双密集。多租户、大批量的场景请把删除工作分散到多个 compactor 实例横向扩展别指望单机扛。请求存储与迁移boltdb 与 sqlite 双写思路delete_request_store和delete_request_store_db_type是两个不同维度前者是删除请求数据文件所在的对象存储位置后者是 compactor 本地使用的数据库引擎默认boltdb可切sqlite。两套实现分别在 delete_requests_db_boltdb.go 和 delete_requests_db_sqlite.go。想从 boltdb 迁到 sqlite 又不丢请求用备份库双写compactor: delete_request_store_db_type: sqlite # 目标引擎 backup_delete_request_store_db_type: boltdb # 迁移期间同时写老引擎backup_delete_request_store_db_type当前只支持boltdb见 flag 说明语义就是迁移期间新请求同时写进备份库老数据仍可被读取。等迁移确认无遗漏后去掉备份配置即可。这也是为什么保留一个已开版本控制的delete_request_store桶格外重要本地引擎迁移出问题桶里的请求数据才是兜底。避坑清单与运维检查项上线前逐项过一遍⚠️对象存储桶版本控制已开启——包括日志数据桶和delete_request_store桶。误删之后这是唯一能恢复的路径。先用filter-only观察再切filter-and-delete。同一批流、同一时间窗口先让删除请求以纯过滤模式跑几天用查询结果核对命中范围是否符合预期再物理落地。控制分片粒度。大批量带过滤器的删除用max_interval把单次分片压小如2h避免一条请求横跨数天导致执行时间失控注意它只能小于等于delete_max_interval。取消期别调太短。flag 注释建议delete_request_cancel_period至少 24h——调成 1h 看似删得快实则是把操作错误的缓冲时间压缩到几乎没有。盯指标。loki_compactor_deletion_*家族重点看请求积压received 与 processed 的差值走势和deletionFailures持续积压就横向扩 compactor。缺 chunk 时的逃生门要慎用。deletion_ignore_missing_chunks默认false可在索引指向的 chunk 在对象存储里丢失时跳过该 chunk、不让整条删除请求卡死被跳过的数量计入loki_compactor_deletion_missing_chunks_total。但源码注释警告得很直白只有在确认真正丢失后才应临时开启——若 chunk 其实还在却被跳过它承载的数据将永远不会被删掉而请求却会显示已完成。Loki 的日志删除把强操作拆成了可反悔的两段提交到执行之间隔着取消期执行之前还隔着 retention 与删除延迟的缓冲。把deletion_mode、分片粒度和监控接好这套能力就能安全地服务于合规与容量需求。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
