3. 租户模型设计:多租户架构、租户标识与资源隔离策略

在 Prometheus 接入策略即代码(Policy as Code, PaC)体系中,租户模型是配额校准与回滚护栏的基石。一个设计良好的租户模型需要同时解决三个核心问题:多租户架构决定了数据与控制面的组织方式;租户标识决定了策略如何绑定到具体业务单元;资源隔离策略决定了配额如何被安全地执行与回滚。

设计原则:租户模型应遵循“标识先行、隔离分层、配额可溯”的原则。每个租户在 Prometheus 生态中必须拥有全局唯一的标识,并且该标识贯穿指标采集、存储、查询与策略评估的全链路。

3.1 多租户架构:控制面与数据面分离

本课程采用 控制面-数据面分离 的多租户架构。控制面(Prometheus Operator / Cortex / Thanos)负责租户管理、策略下发与配额校准;数据面(Prometheus Server / Agent)负责指标采集与本地缓存。这种架构允许租户在数据面独立扩缩容,而配额策略在控制面统一执行。

多租户控制面与数据面分离架构 多租户控制面与数据面分离架构 控制面(Control Plane) 租户管理器 策略引擎 配额校准器 审计日志 数据面(Data Plane) Prometheus Server Agent 模式 Remote Write 说明:控制面通过 gRPC/HTTP API 向数据面下发租户标识与配额策略;数据面定期上报指标使用量用于配额校准。 回滚护栏在控制面策略引擎中实现,确保配额变更可追溯、可回退。

3.2 租户标识:全局唯一与策略绑定

租户标识(Tenant ID)是连接指标数据与配额策略的桥梁。在 PaC 体系中,租户标识必须满足以下要求:

标识属性 要求 示例 说明
全局唯一 跨集群、跨环境不重复 prod-pay-001 使用“环境-业务线-序号”组合
不可变 一旦分配,生命周期内不变 tnt-3a8f2c1b 推荐使用 UUID 或哈希值
可读性 运维人员可快速识别归属 team-alpha 在 UUID 基础上附加业务标签
策略绑定 直接映射到 PaC 策略文件 tenant: prod-pay-001 在 YAML 策略中作为 selector
最佳实践:在 Prometheus 的 Remote Write 协议中,通过 X-Scope-OrgID 头部传递租户标识(Cortex/Thanos 标准)。在 PaC 策略文件中,使用 tenant_id 字段进行匹配:
# 策略文件:quotas/prod-pay-001.yaml
apiVersion: monitoring.pac.io/v1
kind: TenantQuota
metadata:
  tenant_id: "prod-pay-001"
  labels:
    environment: production
    business: payment
spec:
  max_series: 500000
  max_samples_per_second: 10000
  max_remote_write_bytes: 104857600  # 100MB
  rollback_guard:
    enabled: true
    cooldown_period: "15m"

3.3 租户资源隔离策略:三层隔离模型

资源隔离策略决定了配额如何被强制执行。本课程采用 三层隔离模型,从采集、存储到查询逐层保障租户间的资源公平性。

租户资源三层隔离模型 租户资源三层隔离模型 L1 采集隔离(Ingestion Isolation) 每个租户拥有独立的采集配置(scrape_config),通过 rate_limit 与 sample_limit 控制采集速率 L2 存储隔离(Storage Isolation) 基于租户标识分片存储(Thanos Bucket / Cortex Ingester),限制每租户的 series 总数与 TSDB 块大小 L3 查询隔离(Query Isolation) 查询时强制注入租户过滤器(Tenant Enforcer),防止跨租户数据泄露;限制并发查询数与查询深度 三层隔离共同构成配额校准的“硬边界”,任何一层触发阈值都会触发回滚护栏。

3.4 隔离策略对比与选型

不同的隔离策略适用于不同的场景。下表对比了三种常见隔离方式的优缺点:

隔离策略 粒度 资源开销 隔离强度 适用场景
独立 Prometheus 实例 租户级 高(每租户一个实例) 最强 金融核心、合规敏感业务
单实例 + 标签过滤 标签级 低(共享实例) 弱(依赖标签一致性) 开发测试、低风险业务
控制面代理 + 租户分片 租户级(推荐) 中(共享控制面) 强(策略强制执行) 生产环境、多业务线共存
注意:在 PaC 回滚护栏场景中,不推荐使用“单实例 + 标签过滤”方式。因为标签过滤无法防止租户 A 的采集器意外写入租户 B 的指标,导致配额校准失效。必须使用控制面代理(Cortex/Thanos)或独立实例来保证隔离的确定性。

3.5 租户生命周期与配额校准流程

租户模型设计完成后,需要与配额校准流程集成。以下是标准流程:

  1. 租户注册:通过 PaC API 创建租户,生成全局唯一 Tenant ID,并写入租户管理器。
  2. 初始配额分配:根据业务预估,在策略引擎中生成初始配额策略(YAML),并绑定到租户。
  3. 数据面部署:Prometheus Agent 启动时携带 Tenant ID,向控制面注册并拉取配额策略。
  4. 持续校准:配额校准器定期(默认 5 分钟)对比实际使用量与配额阈值,生成校准建议。
  5. 回滚触发:当校准建议导致配额缩减超过 20% 时,回滚护栏自动生效,暂停变更并通知运维。
  6. 审计记录:所有租户配额变更写入审计日志,支持按 Tenant ID 追溯历史版本。
关键指标:在 Prometheus 中,通过以下指标监控租户隔离效果:
# 租户系列数(按租户聚合)
sum by (tenant_id) (prometheus_tsdb_head_series)

# 租户采集速率(每秒样本数)
sum by (tenant_id) (rate(prometheus_tsdb_head_samples_appended_total[5m]))

# 租户配额违规次数
tenant_quota_violations_total{tenant_id="prod-pay-001"}

# 回滚护栏触发次数
rollback_guard_triggered_total{tenant_id="prod-pay-001"}