4. Prometheus 多租户方案：Thanos Receiver 的租户路由、Cortex/Mimir 的租户认证与数据分片
在云原生可观测性体系中，Prometheus 作为核心指标采集器，其单实例架构无法满足多团队、多环境的租户隔离需求。本章深入剖析三种主流的多租户扩展方案：Thanos Receiver、Cortex 与 Mimir，重点阐述其租户路由、认证与数据分片机制，帮助你在实际部署中做出合理的技术选型与参数调优。
4.1 多租户隔离的核心挑战
多租户场景下，Prometheus 原生架构面临以下问题：
- 数据混杂：所有指标写入同一时序数据库，无法按租户隔离查询与存储。
- 认证缺失：无内置租户身份识别机制，任意客户端均可写入/读取。
- 资源争抢：高负载租户可能影响其他租户的查询性能与数据可靠性。
- 分片困难：单实例存储容量有限，水平扩展需手动分片且难以动态调整。
关键原则：多租户方案的核心在于“数据写入时打标、查询时过滤、存储时分片”。Thanos、Cortex、Mimir 分别以不同方式实现这一原则。
4.2 Thanos Receiver：基于标签的租户路由
Thanos Receiver 是 Thanos 组件链中的写入入口，它通过 HTTP 头部 或 指标标签 实现租户路由，将不同租户的数据转发至对应的 Hash Ring 节点。
4.2.1 租户路由机制
- 租户标识提取：Receiver 从请求 Header（如
THANOS-TENANT）或 Prometheus 远程写入的__tenant__标签中提取租户 ID。 - 一致性哈希路由：根据租户 ID 计算哈希值，将数据路由到 Hash Ring 上对应的 Receiver 实例。
- 数据本地化：同一租户的数据始终写入固定的 Receiver 实例，便于后续查询优化。
配置示例（Thanos Receiver 启动参数）：
# 启用租户路由
--receive.tenant-header=THANOS-TENANT
--receive.default-tenant-id=default
# Hash Ring 配置
--receive.hashrings-file=/etc/thanos/hashrings.json
--receive.local-endpoint=192.168.1.10:109014.2.2 参数调优要点
| 参数 | 说明 | 推荐值 |
|---|---|---|
--receive.tenant-header |
指定 HTTP 头部字段名，用于提取租户 ID | THANOS-TENANT |
--receive.hashrings-file |
Hash Ring 配置文件路径，定义分片节点 | 根据集群规模动态调整 |
--receive.replication-factor |
数据副本数，提高可用性 | 2 或 3 |
--receive.grpc-compression |
gRPC 传输压缩，减少网络开销 | snappy |
4.3 Cortex / Mimir：租户认证与数据分片
Cortex 与 Mimir（Grafana Labs 维护的 Cortex 演进版）提供了更完善的多租户架构，核心组件包括 Distributor、Ingester、Querier，并内置租户认证与数据分片能力。
4.3.1 租户认证机制
- X-Scope-OrgID 头部：所有请求必须携带此 HTTP 头部，值为租户唯一标识（如
team-alpha）。 - 认证中间件：Distributor 与 Querier 通过中间件验证 OrgID 合法性，拒绝未携带或无效的请求。
- 多租户数据隔离：Ingester 按 OrgID 将数据写入不同的 TSDB 块，查询时自动过滤。
安全提示：切勿在生产环境中使用
--auth.enabled=false 禁用认证。若需跳过认证（如内部测试），应通过反向代理层注入固定 OrgID。
4.3.2 数据分片策略
Cortex/Mimir 采用 哈希分片 与 时间分片 结合的方式：
- 哈希分片：根据
series ID（由指标名+标签组合的哈希值）将数据分布到不同的 Ingester 实例。 - 时间分片：Ingester 按时间窗口（默认 2 小时）将数据切分为独立的 TSDB 块，便于压缩与查询。
- 数据复制：支持配置副本因子（默认 3），确保单节点故障时数据不丢失。
| 组件 | 分片角色 | 关键配置 |
|---|---|---|
| Distributor | 接收写入请求，验证 OrgID，计算哈希并转发 | distributor.ring.replication-factor |
| Ingester | 按 OrgID+时间窗口存储数据，定期压缩 | ingester.max-chunk-age、ingester.chunk-idle-period |
| Querier | 根据查询的 OrgID 与时间范围，从对应 Ingester 读取数据 | querier.max-concurrent |
4.4 方案对比与选型建议
| 维度 | Thanos Receiver | Cortex / Mimir |
|---|---|---|
| 租户标识 | HTTP Header 或标签 | X-Scope-OrgID 头部 |
| 认证强度 | 弱（依赖外部代理） | 强（内置中间件） |
| 分片粒度 | 租户级别（Hash Ring） | Series 级别（哈希+时间） |
| 数据复制 | 支持（replication-factor） | 支持（默认 3 副本） |
| 查询隔离 | 需手动配置查询路由 | 自动按 OrgID 过滤 |
| 运维复杂度 | 中等 | 较高（组件多） |
| 适用场景 | 中小规模、快速部署 | 大规模、企业级多租户 |
选型建议：
- 若团队规模小、租户数量少（< 10），且希望快速集成现有 Prometheus 生态，优先选择 Thanos Receiver。
- 若需要严格的租户认证、细粒度数据分片与高可用保障（如金融、电商场景），推荐 Cortex 或 Mimir。
- Mimir 作为 Cortex 的演进版，在性能与易用性上更优，新项目建议直接采用 Mimir。
4.5 参数调优实践
4.5.1 Thanos Receiver 关键参数
--receive.tenant-header：确保与客户端约定一致的头部字段名。--receive.hashrings-file：定期更新 Hash Ring 配置，避免节点变更导致数据倾斜。--receive.replication-factor：根据集群可靠性要求设置，建议至少 2。--receive.grpc-compression：启用压缩可减少网络带宽消耗，但会增加 CPU 开销。
4.5.2 Cortex/Mimir 关键参数
| 组件 | 参数 | 说明 | 推荐值 |
|---|---|---|---|
| Distributor | distributor.ring.replication-factor |
写入副本数 | 3 |
| Ingester | ingester.max-chunk-age |
单个 TSDB 块的最大时间跨度 | 2h |
| Ingester | ingester.chunk-idle-period |
无新数据写入后，等待多久关闭块 | 30m |
| Querier | querier.max-concurrent |
最大并发查询数 | 根据 CPU 核数调整 |
| Querier | querier.timeout |
查询超时时间 | 2m |
调优口诀：写入看 Ingester 块大小，查询看 Querier 并发度，分片看 Hash Ring 均匀性，认证看 OrgID 完整性。
4.6 避坑指南
- 租户 ID 冲突：确保不同租户的 OrgID 全局唯一，避免数据交叉写入。
- Hash Ring 不均衡：定期监控各节点数据量，必要时手动调整分片权重。
- 认证绕过风险：禁止在公网暴露未启用认证的 Distributor 或 Receiver 端口。
- Ingester 内存泄漏：合理设置
ingester.max-chunk-age与ingester.chunk-idle-period，避免块长时间不关闭导致内存持续增长。 - 查询超时：对于跨租户的聚合查询，建议设置合理的超时时间，避免阻塞 Querier 线程池。