4、采集作业平台架构概览：数据采集层、传输层、存储层、查询层的多租户设计要点

采集作业平台作为多租户 PromQL 聚合查询的底层载体，其架构设计直接决定了隔离能力与查询性能的上限。平台采用经典的四层架构：数据采集层、传输层、存储层与查询层。每一层都需要针对多租户场景进行专项设计，才能确保租户间数据不串、资源不抢、性能不降。

4.1 数据采集层：租户身份绑定与标签注入

采集层是数据进入平台的第一个关口，也是多租户隔离的起点。核心设计要点如下：

• Agent 级租户绑定：每个采集 Agent 在启动时通过配置文件或服务发现机制绑定唯一租户 ID（tenant_id），Agent 采集的所有指标数据自动携带该租户标签。
• 标签强制注入：平台在采集端对每个数据点强制注入 tenant_id、project_id 等隔离标签，禁止用户自定义标签覆盖系统级标签。
• 采集任务路由：根据租户 ID 将采集任务分发到对应的 Agent 组，避免跨租户数据混采。
• 采集资源隔离：每个租户的 Agent 拥有独立的 CPU、内存配额，防止某个租户的采集任务影响其他租户。

4.2 数据传输层：独立通道与背压控制

传输层负责将采集到的数据可靠地送达存储层。多租户场景下，传输层需要解决“数据拥堵”和“跨租户干扰”两个核心问题。

• 租户级传输队列：每个租户拥有独立的缓冲队列（如 Kafka Topic 分区或内存队列），避免一个租户的数据量暴增阻塞其他租户。
• 限流与熔断：基于租户 ID 实施独立的速率限制（QPS/带宽），当某个租户超过配额时触发降级或熔断，不影响全局传输链路。
• 数据校验与重试：传输过程中校验数据携带的租户标签是否合法，标签缺失或异常的数据直接丢弃并告警。
• 传输加密：租户间数据传输通道使用独立的加密密钥，防止数据在传输过程中被其他租户窃听。

4.3 数据存储层：分片存储与生命周期管理

存储层是数据隔离的“压舱石”。Prometheus 生态中，Thanos、VictoriaMetrics、M3DB 等组件都提供了多租户存储能力。设计要点如下：

• 租户级存储分片：按 tenant_id 对数据进行哈希分片，每个分片独立存储，查询时只需扫描对应分片。
• 时序分区策略：在分区键中嵌入 tenant_id，确保同一租户的数据在物理存储上连续，提升查询效率。
• 独立保留策略：不同租户可以配置不同的数据保留时长（如免费租户 7 天，付费租户 30 天），存储层按租户执行数据过期清理。
• 存储配额管理：限制每个租户的存储容量上限，超量时拒绝写入或触发告警。

4.4 数据查询层：身份认证与 PromQL 重写

查询层是用户与数据交互的界面，也是多租户隔离的“最后一道防线”。即使采集、传输、存储都做了隔离，查询层如果出现漏洞，租户依然可能越权访问其他租户的数据。

• 租户身份认证：每个查询请求必须携带有效的租户凭证（ / ），查询层解析并注入当前租户上下文。
• PromQL 自动重写：查询层在收到 PromQL 后，自动在查询条件中追加 tenant_id="当前租户" 过滤条件，确保查询范围被限制。
• 结果后过滤：对于某些无法在查询阶段完全隔离的场景（如聚合查询），在返回结果前再次校验每条数据的租户归属。
• 查询资源配额：限制每个租户的并发查询数、查询时间范围、返回数据点数，防止恶意查询拖垮存储层。

4.5 四层隔离设计对比总结

下表从隔离粒度、性能影响、实现复杂度三个维度对比四层的多租户设计特点，帮助你在实际架构选型时做出权衡。