Thanos Compactor 删除延迟机制解析与最佳实践

问题背景

在使用Thanos监控系统时，Compactor组件负责处理时序数据的压缩(compaction)和降采样(downsampling)工作。近期有用户报告了一个典型问题：Compactor虽然能够正常标记待删除的块(block)，但这些被标记的块却未被实际删除，而手动使用thanos tools bucket cleanup命令却能成功清理。

问题本质分析

这个现象实际上与Thanos Compactor的删除延迟机制(delete-delay)直接相关。Thanos设计这一机制是为了防止误删除重要数据，特别是在分布式环境下可能出现的数据竞争情况。

默认情况下，Thanos Compactor会为待删除的块设置一个48小时的延迟窗口。在这段时间内，块虽然被标记为待删除状态(通过deletion-mark.json文件)，但不会被物理删除。只有当标记时间超过配置的delete-delay值后，Compactor才会在后续的清理周期中实际删除这些块。

解决方案验证

用户通过调整--delete-delay参数解决了这个问题。将删除延迟设置为一个更小的值(如0s)可以立即清理被标记的块。这在某些需要快速回收存储空间的场景下是可行的解决方案。

深入技术细节

1. 标记机制：当块满足删除条件(如超过保留期限)时，Compactor会在块目录下创建deletion-mark.json文件
2. 清理流程：Compactor定期执行清理任务时，会检查标记文件的创建时间，只有超过delete-delay配置时长的标记才会被处理
3. 并行处理：Compactor的清理操作与压缩/降采样操作是并行进行的，通过日志可以看到"cleaning of blocks marked for deletion done"的提示

最佳实践建议

1. 生产环境：建议保持默认的48小时删除延迟，防止意外数据丢失
2. 测试环境：可以适当降低删除延迟，加速存储回收
3. 监控配置：定期检查S3存储中deletion-mark.json文件的数量和存在时间
4. 紧急清理：确实需要立即清理时，可以使用thanos tools bucket cleanup --delete-delay=0s命令

参数关系说明

值得注意的是，delete-delay参数与保留策略参数(retention.resolution-*)是相互独立的：

• retention.resolution-*决定块何时被标记为待删除
• delete-delay决定标记后多久实际删除

两者共同作用，但不互相覆盖，合理配置这两个参数组才能实现精确的存储管理。

总结

Thanos Compactor的删除延迟机制是系统安全性的重要保障。理解这一机制的工作原理，可以帮助运维人员根据实际业务需求合理配置参数，在数据安全性和存储效率之间取得平衡。对于大多数生产环境，建议保持默认配置；而在存储压力较大或测试环境中，可以适当调整以优化资源使用。