4. 多租户模型设计：基于 Tenant ID 的隔离策略、数据平面与控制平面分离

在多租户可观测性架构中，核心挑战在于如何让多个租户共享同一套基础设施，同时保证数据隔离、资源公平和运维安全。本章聚焦于基于 Tenant ID 的隔离策略，以及将系统拆分为 数据平面 与 控制平面 的设计方法。

4.1 基于 Tenant ID 的隔离策略

Tenant ID 是贯穿整个可观测性管道的唯一租户标识。从数据采集、传输、存储到查询，每个环节都必须携带并校验该标识。常见的隔离粒度包括：

4.2 数据平面与控制平面分离

将系统拆分为数据平面与控制平面，是多租户可观测性架构的关键设计原则。这种分离带来了以下好处：

• 故障隔离： 数据平面的故障（如 Collector 崩溃、存储延迟）不会影响控制平面的可用性，租户仍可进行配置变更。
• 弹性伸缩： 数据平面可按租户流量独立扩缩，控制平面则按租户数量和管理请求扩缩。
• 安全边界： 控制平面持有全局配置和认证密钥，数据平面仅处理带 Tenant ID 的遥测数据，降低横向移动风险。

下图展示了数据平面与控制平面的典型交互流程：

4.3 Tenant ID 在 OTel 管道中的传递

在 OpenTelemetry 生态中，Tenant ID 通常通过 Resource 属性 或 Span/Log/Metric 属性 传递。推荐的做法是在 SDK 初始化阶段注入 tenant.id，并在 Collector 中通过处理器进行校验和路由。

以下是一个典型的 Collector 配置片段，展示如何基于 Tenant ID 进行数据路由：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  attributes/tenant:
    actions:
      - key: tenant.id
        action: extract
        pattern: ^.*$
  filter/tenant:
    error_mode: ignore
    traces:
      span:
        - 'attributes["tenant.id"] == nil'
    metrics:
      datapoint:
        - 'attributes["tenant.id"] == nil'
    logs:
      log_record:
        - 'attributes["tenant.id"] == nil'

exporters:
  otlp/tenant_a:
    endpoint: "storage-tenant-a:4317"
    headers:
      "x-tenant-id": "tenant-a"
  otlp/tenant_b:
    endpoint: "storage-tenant-b:4317"
    headers:
      "x-tenant-id": "tenant-b"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/tenant, filter/tenant]
      exporters: [otlp/tenant_a, otlp/tenant_b]

4.4 隔离策略对比与选型建议

下表总结了不同隔离策略在关键维度上的表现，帮助你在架构设计时做出选择：

4.5 数据平面内部隔离架构

在数据平面内部，可以进一步将隔离策略落实到 Collector 集群、存储后端和查询服务中。下图展示了一个基于 Tenant ID 分片的 Collector 集群架构：

4.6 关键设计要点

• Tenant ID 注入点： 在 SDK 初始化、Collector 入口、API 网关三个位置强制注入或校验 Tenant ID，确保端到端链路完整。
• 控制平面无状态化： 控制平面组件应设计为无状态，便于水平扩展和故障转移。租户元数据存储在外部数据库（如 etcd 或 Redis）中。
• 数据平面健康检查： 控制平面应定期探测数据平面各组件的健康状态，当某个分片不可用时，自动将流量切换到备用分片或降级处理。
• 审计与计量： 在控制平面记录每个租户的数据量、查询次数和错误率，为后续的计费和容量规划提供依据。