Flipkart 使用分层联邦将 Prometheus 扩展到 8000 万个指标

Flipkart的工程师最近发表了一份详细的案例研究，描述了他们如何通过在Prometheus中采用分层联邦设计来克服监控中的严重可扩展性限制。迁移是由他们的 API 网关层驱动的，其中大约有 2000 个实例，每个实例大约产生 40000 个指标，从而导致同时产生了令人震惊的 8000 万个时间序列数据点。

最初，Flipkart 使用StatsD进行指标聚合，但他们发现它无法扩展。长时间跨度的查询使存储变得拥堵，使得历史分析变得不切实际。为了解决这个问题，他们转向了 Prometheus，它更好地支持了高维度查询，并能与 Kubernetes 和 exporter 生态系统很好地集成。

其扩展解决方案的核心在于分层联邦：本地 Prometheus 服务器从服务中摄取指标，应用记录规则以丢弃高基数实例标签，并通过/federate 端点暴露聚合序列。然后，联邦服务器向上抓取选定的聚合指标，将它们写入长期存储和仪表板。这种分层设计大大减少了指标基数和对中央服务器的负载。

为了进一步降低基数，Flipkart 采用了诸如丢弃服务或集群等稳定维度的实例标签等策略。对于延迟指标（p95，p99），他们发布了汇总统计数据（平均值、最大值、最小值），而不是每个实例的序列。这种方法将 8000 万个原始系列压缩成数万个集群级别的指标。

作者还对权衡提出了警告：当你需要跨集群调试每个实例的异常或在小型部署中工作时，分层联邦的用处不大，单个 Prometheus 实例就足够了。他们建议不要盲目地将原始指标向上镜像，而是强调过滤和选择性联邦。

Flipkart 的经验强调了平面监控架构在规模上的局限性，并说明了联邦、聚合规则和标签修剪如何使大规模可观测性变得可管理。他们的方法为在云原生环境中面临爆炸性指标增长的组织提供了一个实用的蓝图。

虽然 Flipkart 的分层联邦方法提供了简单性和与原生 Prometheus 的强大对齐，但其他面临类似扩展挑战的组织已经转向了像 Thanos、Cortex/Mimir 或 VictoriaMetrics 这样的分布式系统，每种系统都以不同的方式解决了规模和保留问题。

例如，Thanos通过长期存储和全球查询能力扩展了 Prometheus。Thanos 不是依赖多级联邦，而是将边车组件附加到每个 Prometheus 实例，然后将指标上传到对象存储（例如，S3 或 GCS）。集中式查询器可以跨集群进行查询，提供统一视图，无需聚合或丢弃标签。这消除了手动联邦设置，但引入了额外的组件和操作开销。与 Flipkart 的分层模型相比，Thanos 提供了更强的全局查询可见性，但需要管理更多的基础设施和存储。

Cortex（及其现代分支，Grafana Mimir）采取了一种更云原生、水平可扩展的方法。指标存储在基于微服务（如分发者、采集者和查询者）的多租户分布式时序数据库中。与 Flipkart 的分层联邦不同，Cortex 和 Mimir 使用一致性哈希和对象存储自动分片数据，以较少的手动配置实现大规模和持久性。需要权衡的是复杂性——部署和优化 Cortex 或 Mimir 需要分布式系统方面的专业知识，而 Flipkart 的方法可以使用原生 Prometheus 工具实现。

另一方面，VictoriaMetrics采取了中间立场。它支持 Prometheus 远程读写 API，但强调性能和压缩效率。它的单二进制设置使其在操作上是轻量级的，但仍然可以处理数千万的指标。对于优先考虑部署简便和高效长期保留的团队，VictoriaMetrics 通常提供了一个比联邦和 Thanos 风格架构更简单的替代方案。

Flipkart 选择依赖分层联邦而不是这些分布式后端，反映了控制、简单性和增量可扩展性之间的平衡。它使 Prometheus 在很大程度上保持了无状态，避免了像对象存储这样的外部依赖，并保持了原生查询语义——这在大型、多集群的 Kubernetes 环境中至关重要。然而，随着组织的进一步扩展，采用将联邦与长期后端（如 Thanos 或 VictoriaMetrics）配对的混合架构可能会进一步增强保留、跨集群查询和弹性。

原文链接：

https://www.infoq.com/news/2025/10/flipkart-prometheus-80million/