Prometheus大规模监控：如何突破存储与查询瓶颈？

Prometheus作为云原生时代的主流监控方案，在单机或小规模集群中表现卓越。然而，当监控数据量达到数十亿乃至上百亿指标时，其内置的TSDB（时间序列数据库）在存储成本和历史数据查询效率方面会很快显露出瓶颈。特别是在需要跨租户或进行长时间范围（如年级别）的数据分析时，原生Prometheus的局限性尤为突出。

作为在大型互联网公司摸爬滚打多年的SRE，我深知这些痛点。这里分享一些我们在实践中总结出的解决方案和常用工具，旨在降低存储成本的同时，显著提升历史数据查询速度。

Prometheus面临的挑战

原生Prometheus的设计初衷是面向短期、高精度的实时监控。它的TSDB将数据存储在本地磁盘上，并通过WAL（Write-Ahead Log）保证数据写入性能。但这种架构在大规模场景下存在以下问题：

1. 存储扩展性有限： 单个Prometheus实例的存储容量受限于其所在主机的磁盘空间，难以水平扩展。
2. 查询性能瓶颈： 长时间范围或高基数（Cardinality）的查询，需要从磁盘加载大量数据，对CPU和内存消耗巨大，查询耗时会急剧增加。
3. 数据高可用性欠缺： 单实例模式下，Prometheus本身不提供数据冗余和高可用，一旦实例故障，数据可能丢失或不可用。
4. 跨集群/租户查询困难： 缺乏一个统一的入口来查询多个Prometheus实例的数据。

解决方案与实践

针对上述挑战，业界已经发展出多种成熟的方案，核心思想都是将存储和查询层与Prometheus解耦，并引入分布式和长期存储的能力。

1. 长期存储（Long-Term Storage, LTS）

将Prometheus采集到的数据持久化到专门的分布式存储系统中，是解决存储扩展性和高可用性的关键。常用的LTS方案包括：

• 远程写入（Remote Write）： 这是Prometheus提供的标准接口。Prometheus可以将采集到的数据实时写入到支持Prometheus remote_write 协议的外部存储系统。
• 存储系统选择：
  • Thanos Store Gateway： Thanos生态的一部分，可以将Prometheus的TSDB数据块上传到对象存储（如S3、OSS、MinIO等），并提供查询接口。
  • Cortex/Mimir： 云原生多租户、高可用、可扩展的时序数据库，通常作为托管服务或自建方案，底层也常使用对象存储。
  • VictoriaMetrics： 一体化的、高性能、可扩展的时序数据库，兼容Prometheus的remote_write和remote_read API，支持单体和集群模式。
  • M3DB： Uber开源的高性能、分布式时序数据库，也支持remote_write。

优势：

• 无限的存储扩展能力（基于对象存储）。
• 存储成本大幅降低（对象存储通常比块存储便宜）。
• 数据高可用和持久性增强。

2. 数据降采样与聚合（Downsampling & Aggregation）

对于长时间范围的趋势分析，我们通常不需要秒级甚至分钟级的原始数据。通过对历史数据进行降采样和聚合，可以大幅减少存储量和查询时的数据处理量，从而提高查询速度。

• 实现方式：
  • Thanos Compact： Thanos组件之一，负责对S3中的数据块进行合并、降采样和删除过期数据。它可以在后台自动处理，生成不同粒度的聚合数据。
  • Recording Rules： 在Prometheus或其查询层（如Thanos Querier）中配置Recording Rules，预先计算一些常用的聚合指标并存储起来。例如，计算每小时的平均CPU利用率，而不是每次查询都从原始数据计算。
  • LTS自带功能： 一些LTS方案（如Cortex、Mimir、VictoriaMetrics）可能内置了降采样或数据压缩能力。

优势：

• 显著减少长期存储的数据量。
• 大幅加速长时间范围的查询。

3. 分布式查询层（Distributed Query Layer）

当数据分散在多个Prometheus实例和长期存储中时，需要一个统一的查询入口来聚合和处理这些数据。

• Thanos Query： Thanos生态的核心组件，它能够并行查询多个Prometheus Sidecar（连接到Prometheus实例）、Thanos Store Gateway（连接到对象存储）以及其他Thanos Query实例，并将结果聚合后返回。它完全兼容PromQL。
• Cortex/Mimir Query Frontend： 提供了查询队列、查询分发、查询结果缓存等功能，能有效提升大规模查询的稳定性和性能。
• VictoriaMetrics VMSelect/VMCluster： 作为VictoriaMetrics集群的查询入口，能够透明地从集群中的多个存储节点获取数据并进行聚合。

优势：

• 提供统一的PromQL查询入口，实现全局视图。
• 支持跨多个Prometheus实例和长期存储的数据查询。
• 通过并发查询和结果聚合，提升大规模查询效率。

推荐实践方案：Thanos / VictoriaMetrics

综合来看，目前最主流且成熟的两种解决方案是 Thanos 和 VictoriaMetrics。

Thanos方案

• 架构：
  • 每个Prometheus实例旁部署一个 Thanos Sidecar，负责将Prometheus本地数据块上传到对象存储（如S3），并提供StoreAPI接口供Thanos Querier查询。
  • Thanos Store Gateway：用于暴露对象存储中的历史数据，同样提供StoreAPI。
  • Thanos Querier：统一查询入口，从Sidecar和Store Gateway获取数据，执行PromQL查询。支持去重、合并等。
  • Thanos Compact：后台任务，负责对对象存储中的数据进行降采样、合并、删除。
  • 可选：Thanos Ruler：用于执行Recording Rules和Alerting Rules。
• 优势：
  • 与Prometheus原生集成度高，非侵入式。
  • 充分利用对象存储的成本优势。
  • 提供了完整的分布式、高可用、长期存储和查询方案。
  • 社区活跃，文档丰富。
• 缺点：
  • 组件较多，部署和维护相对复杂。
  • 引入对象存储带来额外的网络I/O开销。

VictoriaMetrics方案

• 架构：
  • Prometheus通过remote_write将数据写入 VictoriaMetrics 集群。
  • VMInsert：负责数据写入。
  • VMStorage：负责数据存储。
  • VMSelect：负责数据查询。
  • （单体模式下，一个二进制文件包含所有功能）
• 优势：
  • 一体化设计，部署维护简单。 单体VM的性能极高，集群版也相对Thanos简洁。
  • 资源效率高： 官方宣称比Prometheus节省7倍存储空间，比其他TSDB节省更多资源。
  • 查询速度快： 尤其擅长处理高基数和长时间范围查询。
  • 完全兼容PromQL： 无需学习新查询语言。
  • 支持多租户。
• 缺点：
  • 与Prometheus本地存储解耦，数据从Prometheus到VictoriaMetrics有一段路径，需要保证写入的稳定性。

其他优化建议

无论选择哪种分布式方案，以下几点也至关重要：

• 严格控制指标基数（Metric Cardinality）： 高基数是性能杀手。避免在标签中包含高变动性（如请求ID、时间戳）的数据。
• 合理设置保留策略： 针对不同的数据重要性，设置不同的保留时间。
• 预计算（Recording Rules）： 对常用、计算量大的聚合指标进行预计算，存储为新的指标，可以大幅提升Dashboard加载和告警判断速度。
• 硬件优化： 对于Prometheus和LTS组件，选择高性能I/O的磁盘（如NVMe SSD）和充足的内存。

总结

Prometheus在大规模监控场景下的存储和查询瓶颈是必然会出现的问题。通过引入 Thanos 或 VictoriaMetrics 这类分布式时序数据库解决方案，并辅以数据降采样、Recording Rules和基数管理等优化手段，我们完全可以在降低存储成本的同时，显著提升历史数据查询的效率，从而更好地支撑复杂的业务分析和运维决策。选择哪个方案取决于你的团队经验、对复杂度的接受程度以及具体的业务需求。