Cortex 集群多租户指标存储实战：如何实现高效隔离与弹性扩展？

Cortex 最初由 Weaveworks 开发，后来成为 CNCF 生态中备受关注的项目，它的定位很明确：在保留 Prometheus 采集与查询体验的前提下，把指标存储搬到分布式后端，让多个团队、多个集群的监控数据可以统一收进一套系统。对于需要为数十个甚至上百个业务方提供监控平台服务的团队来说，Cortex 的多租户能力是选它的核心理由之一。这篇文章从架构拆解入手，结合实际部署经验，把多租户存储的关键环节讲清楚。

一、Cortex 整体架构与核心组件

Cortex 采用了典型的读写分离架构，数据链路大致是：Prometheus 或 Agent 通过 remote_write 把指标推给 Cortex，经过 distributor 分发后写入 ingester 集群，最终落盘到对象存储（如 S3、MinIO）；查询时，querier 会同时拉取 ingester 中的热数据和 store gateway 中的历史数据，合并后返回给用户。理解这条链路是做好容量规划的前提。

各组件的职责可以这样看：distributor 是写入入口，负责租户校验、配额检查和哈希分片，把每个时间序列路由到对应的多个 ingester 上；ingester 保存最近几小时的热数据在内存中，并定期压缩成块上传到对象存储；querier 对接 PromQL 引擎，实现即时查询和录制规则评估；store gateway 负责从对象存储读取历史块数据；compactor 负责对小块做合并压缩，降低存储成本和查询扇出。

一个容易被忽视的组件是 ruler。如果希望告警规则和录制规则也按租户隔离执行，就需要部署 ruler 组件，并把每个租户的规则文件存到对象存储中。这样每个团队的告警计算互不干扰，也不会因为某一个租户的规则量暴涨而拖垮整个集群。

二、多租户隔离机制详解

Cortex 的多租户识别依赖一个 HTTP 头：X-Scope-OrgID。每个请求必须携带这个头，Cortex 根据它的值把数据、配额、规则全部隔离到独立的命名空间里。这意味着在接入层就要决定租户身份从哪里来，常见的做法是在网关层根据 API Key 或内网身份自动注入这个头，租户自身无法伪造。

启动多租户能力很简单，Cortex 默认开启多租户模式，只需确保配置中 auth_enabled: true 没有被关闭。下面的配置片段展示了典型的基础设置：

auth_enabled: true

server:
  http_listen_port: 9009

distributor:
  pool:
    health_check_ingesters: true

ingester:
  lifecycler:
    ring:
      kvstore:
        store: memberlist
      replication_factor: 3

storage:
  backend: s3
  s3:
    endpoint: minio.internal:9000
    bucket_name: cortex-metrics
    insecure: true

数据隔离层面，Cortex 为每个租户在对象存储中使用独立的前缀路径，块数据按租户目录分开存放，查询时也只会扫描对应租户的数据，物理上不会串数据。配额与限流则通过 limits_config 按租户粒度配置，例如限制每个租户的活跃序列数、写入请求速率和最大查询时间范围。可以为不同租户设置不同档位：

limits_config:
  ingestion_rate: 25000
  max_global_series_per_user: 1500000
  max_query_length: 721h
  per_tenant_override_config: /etc/cortex/overrides.yaml

overrides.yaml 中可以针对个别租户做差异化调整，比如给核心业务租户更高的序列配额，同时限制边缘团队的查询并发，避免大查询打爆 querier。

# overrides.yaml
overrides:
  tenant-a:
    ingestion_rate: 100000
    max_global_series_per_user: 8000000
  tenant-b:
    max_concurrent_queries: 5
    max_query_series: 3000

三、生产环境部署与性能优化建议

硬件规划上，ingester 是资源消耗最大的组件，因为它要把热数据放在内存里。经验值是每 100 万活跃序列大约需要 8 到 12 GB 内存，再加 30% 左右的余量应对高峰。ingester 的副本数建议至少为 3，配合 ring.heartbeat_timeout 合理调整，可以在节点故障时保证写入不丢。distributor 和 querier 是无状态的，可以直接横向扩容，挂在负载均衡后面即可。

存储成本方面，要重视 compactor 的分块策略。适当增大块的时间跨度能减少小块数量，降低对象存储的请求次数，但跨度过大会影响查询裁剪效率，一般从 12 小时块合并到 24 小时或 48 小时比较稳妥。保留期通过 retention_period 设置，不同租户可以配置不同的保留时长，历史数据较多的团队可以用更长周期配合更激进的压缩。

查询优化有几个实用技巧：第一，在所有查询入口强制 max_query_lookback，防止用户查询超过保留期的数据导致全表扫描；第二，利用 query_sharding_total_shards 开启查询分片，把大范围查询拆到多个 querier 并行执行，对高基数的 rate 与聚合查询提升明显；第三，将查询缓存配置为内存加 Redis 两级结构，重复的面板查询命中率能显著提高。

最后提醒一点，多租户场景下务必开启各组件的指标自监控，重点关注每个租户的 discarded samples、写入延迟 P99 和 querier 的查询失败率。Cortex 自身暴露了完整的 Prometheus 指标，配合按租户标签的告警规则，可以在某个租户行为异常时第一时间定位，这也是保障平台长期稳定运行的关键一环。

Cortex多租户指标存储Prometheus修改时间：2026-09-09 22:38:40