Thanos Receive组件内存泄漏问题分析与解决方案

问题背景

在Thanos 0.36.1版本中，Receive组件在router/ingestor模式下运行时出现了严重的内存泄漏问题。具体表现为内存使用量每2小时左右就会达到峰值，最终导致进程因OOM（内存不足）而被终止。这个问题在升级到0.37.1版本后依然存在。

问题现象

通过监控数据可以观察到以下关键现象：

1. 内存使用量呈现周期性增长，大约每2小时达到峰值
2. 即使Prometheus TSDB的head_series指标显示数据已被刷新，内存并未被释放
3. 内存泄漏导致进程最终因OOM被终止
4. 堆内存分析显示内存持续增长

根本原因分析

经过深入调查，发现问题的根本原因与Exemplars（样本）配置有关。在Receive组件的配置中，设置了过高的tsdb.max-exemplars值（100万），这导致了内存的持续增长。

关键点在于：

1. Exemplars数据在Thanos/Prometheus中永远不会被刷新到磁盘
2. 这些数据会一直保留在内存中
3. 默认情况下，Prometheus的Exemplars限制是10万
4. 过高的Exemplars限制会导致内存使用量急剧增加

解决方案

解决这个问题的方案很简单：

1. 移除或显著降低tsdb.max-exemplars的配置值
2. 采用Prometheus的默认值（10万）或根据实际需求调整

实施这个解决方案后，内存使用量立即稳定在1.6GB左右，问题得到彻底解决。

技术细节

Exemplars的工作原理

Exemplars是Prometheus/Thanos中的一种特殊数据，用于存储与时间序列相关联的跟踪信息。与常规指标数据不同：

1. Exemplars不会被写入磁盘
2. 它们会一直保留在内存中
3. 没有自动的过期或刷新机制
4. 完全依赖配置的数量限制来控制内存使用

最佳实践建议

1. 谨慎配置Exemplars数量限制
2. 监控Receive组件的内存使用情况
3. 考虑实际需求设置合理的Exemplars保留数量
4. 对于不需要Exemplars的场景，可以完全禁用

总结

这个案例展示了配置参数对系统稳定性的重要影响。通过合理配置Exemplars数量限制，可以有效避免内存泄漏问题。这也提醒我们，在采用高级功能时需要充分理解其实现机制和资源消耗特性。

对于Thanos Receive组件的部署，建议在生产环境中严格监控内存使用情况，并根据实际负载调整相关参数，以确保系统的稳定运行。