1. 多租户概述：什么是多租户、多租户在可观测性中的挑战、为什么需要数据管道隔离
1.1 什么是多租户
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时为多个独立的“租户”（Tenant）提供服务，每个租户拥有逻辑隔离的数据、配置和用户权限，彼此互不可见。在可观测性领域，租户通常对应一个业务部门、一个项目团队、一个客户环境或一个微服务集群。
多租户的核心特征包括：
- 资源共享：多个租户共享同一套基础设施（如 Collector、Backend 集群），降低运维成本。
- 逻辑隔离：租户之间的数据、配置、访问权限在逻辑上严格分离，防止数据泄露或误操作。
- 可扩展性：新租户的加入不需要部署新的独立实例，只需在现有架构中分配资源。
- 计费与配额：每个租户的用量可独立计量，支持按租户设置数据保留期、采样率、存储上限等策略。
关键区分：多租户 ≠ 多实例。多实例是为每个租户部署一套独立的软件栈，资源隔离彻底但成本高；多租户是共享实例 + 逻辑隔离，成本低但隔离复杂度高。可观测性场景通常采用多租户架构以应对海量数据。
1.2 多租户在可观测性中的挑战
将多租户引入可观测性系统（Trace、Metrics、Logs）会带来一系列独特挑战，这些挑战远超传统业务系统的多租户问题：
| 挑战维度 | 具体问题 | 典型后果 |
|---|---|---|
| 数据污染 | 租户 A 的 Span/Log 错误写入租户 B 的索引或存储桶 | 查询结果混乱，SLA 违规，审计失败 |
| 资源抢占 | 某个租户突发高流量，耗尽 Collector 或 Backend 处理能力 | 其他租户数据丢失或延迟，全局可用性下降 |
| 配置冲突 | 不同租户需要不同的采样率、属性处理器、批处理策略 | 全局配置无法满足所有租户需求，被迫使用最低公共分母 |
| 身份与授权 | 租户 A 的 API Token 被用于查询租户 B 的数据 | 数据泄露，合规风险 |
| 成本分摊 | 无法准确区分每个租户的存储、计算、网络消耗 | 内部结算不公，预算超支无法追溯 |
| 运维复杂度 | 排查问题时需要同时查看多个租户的上下文 | MTTR 延长，排障效率低下 |
常见误区：很多团队认为只要在数据中增加一个
tenant_id 标签就能实现多租户隔离。实际上，标签只能用于查询过滤，无法阻止数据写入错误、资源抢占或配置冲突。真正的隔离需要从数据管道入口到存储的全链路控制。
1.3 为什么需要数据管道隔离
数据管道隔离（Data Pipeline Isolation）是指在可观测性数据从采集、处理、传输到存储的整个生命周期中，为每个租户建立独立的逻辑通道，确保一个租户的数据行为不会影响其他租户的数据质量、系统性能和访问安全。其必要性体现在以下三个层面：
1.3.1 数据质量层面
- 防止数据交叉污染：隔离的管道确保租户 A 的 Trace 不会因 Collector 路由错误而进入租户 B 的存储后端。
- 独立采样策略：高流量租户可以使用头部采样保留关键请求，低流量租户可以使用尾部采样降低成本，互不干扰。
- 属性处理隔离：每个租户可以自定义属性处理器（如添加环境标签、脱敏敏感字段），而不影响全局管道。
1.3.2 系统稳定性层面
- 资源隔离与限流：通过为每个租户分配独立的 Collector 实例或独立的处理队列，防止“吵闹邻居”问题。
- 故障域隔离：某个租户的管道组件出现故障（如 Exporter 崩溃）不会扩散到其他租户的管道。
- 可预测的性能：每个租户的吞吐量和延迟上限可独立配置，避免全局性能抖动。
1.3.3 安全合规层面
- 租户级认证与授权：每个管道入口点可以绑定独立的 Token 或证书，确保数据来源可信。
- 审计与追溯：隔离的管道使得每个租户的数据流路径清晰可查，满足 SOC2、HIPAA 等合规要求。
- 数据保留策略：不同租户可以设置不同的数据保留周期（如 7 天 vs 90 天），隔离管道使存储后端能按租户执行生命周期管理。
核心结论：没有数据管道隔离的多租户只是“伪多租户”。真正的多租户可观测性系统必须从数据入口开始就建立租户维度的隔离边界，而不是依赖后置的标签过滤或存储分区。
1.4 多租户数据管道隔离架构总览
下图展示了多租户数据管道隔离的核心架构层次，从数据源到存储的每个阶段都实现了租户维度的隔离：