Thanos Compactor 二次降采样过程中产生重复块问题分析

问题背景

在Thanos监控系统的实际部署中，Compactor组件负责对时间序列数据进行降采样(Downsampling)操作。近期在Thanos v0.35.1版本中发现了一个关键问题：当Compactor执行第二次降采样过程时，会为已经完成第一次降采样的块创建重复副本。

问题现象

通过日志分析可以清晰地观察到问题现象：

1. 第一次降采样过程：Compactor成功将原始块(如01J19GEH5AKEHPGAVAQXS2E0TD)降采样为5分钟分辨率的新块(如01J19GFGYACEHGJBP3C87GA0QB)

2. 第二次降采样过程：Compactor再次对同一个原始块执行降采样，生成另一个相同时间范围和分辨率的块(如01J19GH72N2FD744DPMT4FYCAZ)

3. 后续处理：系统最终会通过GC机制标记并删除其中一个重复块

技术分析

问题根源

深入分析Compactor组件的源代码后，发现问题源于v0.31.0版本后引入的一个变更。在compact.go文件中，原本在每次降采样前都会调用sy.Metas()获取最新的元数据列表，但变更后改为：

1. 在第一次降采样前获取并过滤元数据列表
2. 将过滤后的列表直接用于第二次降采样

这种设计导致第二次降采样时使用了过时的过滤列表，无法感知第一次降采样产生的新块，从而错误地认为原始块仍需降采样。

存储后端无关性

最初怀疑可能是对象存储(S3)的最终一致性导致的问题，但经过以下验证排除了这种可能性：

1. 在NetApp ONTAP S3和Ceph对象网关两种不同存储后端上都复现了相同问题
2. 使用boto3直接测试确认新上传的对象能立即出现在列表中
3. 旧版本(v0.31.0)在相同存储后端上运行正常

影响范围

该问题会导致：

• 存储空间短暂增加(直到GC清理重复块)
• 不必要的计算资源消耗
• 可能影响查询效率(在GC前存在重复数据)

解决方案

修复方案的核心思路是在第二次降采样前重新同步并过滤元数据列表。具体实现包括：

1. 在第二次降采样前调用sy.SyncMetas(ctx)同步最新元数据
2. 重新执行过滤逻辑生成新的过滤列表
3. 使用更新后的列表进行降采样操作

实际测试表明，该修复能有效避免重复块的产生，使降采样过程按预期工作。

技术启示

这个问题为我们提供了几个重要的技术启示：

1. 状态一致性：在分布式系统中，任何基于状态的操作都必须确保使用最新的状态信息

2. 变更影响评估：即使是看似简单的优化(如减少元数据同步次数)也可能引入意想不到的副作用

3. 多环境验证：存储后端的特性差异可能影响系统行为，需要进行充分验证

4. 日志分析价值：详细的运行日志对于诊断此类问题具有不可替代的价值

最佳实践建议

基于此问题的经验，建议在Thanos Compactor的使用和维护中：

1. 版本升级注意：升级后应监控降采样过程，特别是跨大版本升级时

2. 日志监控：设置对重复块产生的告警

3. 存储监控：关注对象存储的使用量异常波动

4. 测试验证：在非生产环境验证新版本的降采样行为

通过这个问题及其解决方案，我们不仅修复了一个具体缺陷，更深化了对分布式时序数据库系统内部工作机制的理解，为后续的系统运维和问题诊断积累了宝贵经验。