Grafana Tempo存储性能优化：解决S3兼容存储启动缓慢问题

在生产环境中部署分布式追踪系统时，存储后端的性能直接影响着系统的可用性和响应速度。本文将以Grafana Tempo为例，深入分析一个典型的存储性能问题及其解决方案。

问题现象分析

在某个使用Hitachi HCP对象存储（S3兼容API）的Tempo部署环境中，运维人员发现Compactor组件启动异常缓慢，耗时从3分钟到20分钟不等。通过日志分析发现，问题出现在blocklist轮询阶段：

level=info ts=2025-03-04T09:26:12.729939165Z caller=poller.go:145 msg="blocklist poll complete" seconds=923.894105031

值得注意的是，存储桶中仅包含约140个对象，总大小约120MB，理论上不应该造成如此严重的延迟。

根本原因诊断

经过深入排查，发现问题的根源在于：

1. 非标准S3实现：使用的Hitachi HCP存储虽然提供S3兼容API，但在目录处理机制上与AWS S3存在差异
2. 空目录问题：该存储系统不会自动清理空目录，导致存储桶中存在大量零字节对象
3. 列表操作瓶颈：Tempo的Compactor组件启动时会执行ListObjectsV2操作扫描所有对象，而大量空目录显著增加了操作耗时

解决方案实施

短期缓解措施

1. 调整并发参数：

   • 降低blocklist_poll_concurrency（建议从默认50降至5）
   • 保持blocklist_poll_tenant_concurrency为默认值1
   • 谨慎调整list_blocks_concurrency（从默认值3开始逐步测试）

2. 监控指标关注：

   • 重点监控tempodb_backend_request_duration_seconds_bucket指标
   • 确保轮询周期低于配置的轮询间隔

长期根治方案

1. 存储清理：

   • 开发定期清理程序，自动移除存储中的空目录对象
   • 建立存储使用规范，避免产生不必要的目录结构

2. 配置优化：

   • 根据实际存储性能调整blocklist_poll相关参数
   • 适当增加Kubernetes存活探针的超时时间

经验总结

1. S3兼容性验证：在使用非AWS S3存储时，必须全面验证其API兼容性，特别是目录和列表操作的行为差异

2. 性能基准测试：建立存储性能基准，包括：

   • 单次ListObjects操作耗时
   • 不同并发级别下的吞吐量
   • 对象数量对操作耗时的影响

3. 监控体系建设：完善的监控应包含：

   • 存储操作延迟指标
   • 存储请求错误率
   • 组件启动各阶段耗时

通过上述措施，最终使Tempo的启动时间从数分钟降至秒级，显著提升了系统可用性。这个案例也提醒我们，在使用非标准存储后端时，需要特别关注其与开源软件设计预期的匹配程度。