3. 租户隔离概念：多租户模型、数据隔离策略与隔离粒度选择

在可观测性平台中，租户隔离是保障多团队、多业务线或不同客户共享同一套观测基础设施时，数据安全与操作边界清晰的核心机制。缺乏合理的隔离设计，会导致链路数据交叉污染、指标误读、告警风暴波及无关方，甚至引发合规风险。

本章从三个维度拆解租户隔离：多租户模型（谁在用）、数据隔离策略（怎么隔）、隔离粒度选择（隔到多细）。

3.1 多租户模型：三种主流架构

多租户模型决定了租户在平台中的身份标识、资源归属与权限边界。在 OTel 链路追踪场景下，常见三种模型：

3.2 数据隔离策略：物理、逻辑与混合

数据隔离策略决定了租户数据在存储、传输与查询阶段的分离程度。在 OTel 链路追踪中，三种策略各有优劣：

3.2.1 物理隔离实战要点

• 存储层：每个租户独立 Elasticsearch 索引或 ClickHouse 表，通过 OTel Collector 的 exporters 配置动态路由。
• Collector 层：使用 groupbyattrs 处理器按 tenant.id 分发到不同 exporter。
• 查询层：每个租户独立 Grafana 数据源，避免跨租户数据泄露。

# OTel Collector 物理隔离配置示例（按租户分发到不同 ES 集群）
processors:
  groupbyattrs:
    keys:
      - tenant.id
exporters:
  elasticsearch/tenant-a:
    endpoints: ["https://es-tenant-a:9200"]
    index: "traces-tenant-a"
  elasticsearch/tenant-b:
    endpoints: ["https://es-tenant-b:9200"]
    index: "traces-tenant-b"
service:
  pipelines:
    traces:
      processors: [groupbyattrs]
      exporters: [elasticsearch/tenant-a, elasticsearch/tenant-b]

3.2.2 逻辑隔离实战要点

• 数据打标：在 OTel SDK 端通过 Resource 注入 tenant.id，确保所有 Span 携带租户标识。
• 查询过滤：Grafana 或查询 API 强制附加 tenant.id 过滤条件，防止越权访问。
• RBAC 集成：结合 OIDC/OAuth2，将用户租户映射到查询过滤器。

// Java OTel SDK 注入租户 ID
Resource resource = Resource.getDefault()
    .merge(Resource.create(Attributes.of(
        AttributeKey.stringKey("tenant.id"), "tenant-a",
        AttributeKey.stringKey("environment"), "production"
    )));
OpenTelemetry openTelemetry = OpenTelemetrySdk.builder()
    .setResource(resource)
    .build();

3.3 隔离粒度选择：从粗到细的决策树

隔离粒度决定了“隔什么”和“隔多细”。在 OTel 链路追踪中，常见粒度层级如下：

3.4 隔离策略选择矩阵

综合多租户模型、数据隔离策略与隔离粒度，以下矩阵帮助你在实际项目中快速决策：