Thanos Compactor 二次降采样过程中的重复块问题分析与解决方案

问题背景

在Thanos监控系统中，Compactor组件负责对时间序列数据进行压缩和降采样处理。近期在Thanos v0.35.1版本中发现了一个关键问题：当Compactor执行第二次降采样(pass)时，会为已在第一次降采样中处理过的块创建重复的降采样块。

问题现象

具体表现为：

1. 第一次降采样过程正常，成功创建5分钟分辨率的降采样块
2. 紧接着的第二次降采样过程中，Compactor会再次处理相同的原始块，创建内容相同但ULID不同的新降采样块
3. 最终系统会识别到重复块并通过GC(垃圾回收)机制标记其中一个块为待删除状态

技术分析

通过深入分析Compactor组件的源代码，发现问题根源在于v0.35.1版本中的一个代码变更。该变更原本是为了优化性能，在第一次降采样前预先过滤元数据列表，然后将过滤后的列表传递给两次降采样过程。

关键问题点：

1. 在两次降采样之间，Compactor会执行SyncMetas同步最新元数据
2. 但过滤后的元数据列表(filteredMetas)没有随同步更新
3. 导致第二次降采样仍然使用旧的过滤列表，无法感知第一次降采样产生的新块

解决方案

修复方案的核心思想是：在第二次降采样前，不仅需要同步元数据，还需要重新生成过滤后的元数据列表。具体实现包括：

1. 在第二次降采样开始时执行元数据同步
2. 基于同步后的最新元数据重新生成过滤列表
3. 使用新过滤列表进行第二次降采样处理

这种方案既解决了重复块问题，又保持了原有功能逻辑的完整性。测试表明，修复后：

• 第一次降采样正常创建5分钟分辨率块
• 第二次降采样正确识别已处理块，跳过重复处理
• 系统资源使用效率提高，避免了不必要的计算和存储开销

影响与意义

该问题修复对Thanos系统有多方面重要意义：

1. 存储效率：避免了重复块占用宝贵的对象存储空间
2. 计算效率：消除了不必要的重复降采样计算过程
3. 系统稳定性：减少了GC机制的工作负担和潜在冲突
4. 数据一致性：确保降采样结果的唯一性和可靠性

对于使用Thanos监控系统的运维团队，建议在升级到包含此修复的版本后，检查现有存储中是否遗留了此类重复块，必要时可手动清理以优化存储使用。

最佳实践建议

基于此问题的经验，在使用Thanos Compactor时应注意：

1. 定期监控Compactor日志，关注降采样过程中的异常情况
2. 对新版本进行充分测试验证后再投入生产环境
3. 建立存储使用情况的监控机制，及时发现异常增长
4. 理解不同存储后端的特性及其对一致性的影响

通过这些问题分析和解决方案，Thanos社区进一步提升了系统的健壮性和可靠性，为用户提供了更稳定的长期存储解决方案。