1. 课程导论：多租户隔离在可观测性中的重要性，OpenTelemetry 管道架构概览
1.1 为什么多租户隔离是可观测性的基石
在云原生环境中，一个可观测性平台往往需要同时服务多个业务线、多个环境（开发/测试/生产）甚至多个外部客户。如果没有清晰的租户隔离，就会出现以下问题：
- 数据泄露风险：租户 A 的敏感指标、日志或链路可能被租户 B 意外访问。
- 资源抢占与噪声干扰：一个租户的突发流量导致整个管道背压，影响其他租户的遥测数据送达率。
- 成本归属模糊：无法准确核算每个租户产生的存储、计算和网络成本。
- 配置冲突：采样率、标签策略、告警规则等全局配置无法按租户差异化生效。
核心观点：多租户隔离不是可观测性的附加功能，而是生产级管道的基础设计约束。隔离粒度决定了平台的信任边界和运营效率。
1.2 多租户隔离的四个关键维度
| 维度 | 隔离目标 | 常见实现方式 |
|---|---|---|
| 数据面隔离 | 租户数据在存储、查询、导出时互不可见 | 标签注入、索引分区、租户级 RBAC |
| 控制面隔离 | 租户独立配置采样、处理器、导出器 | 租户级 Collector 实例、配置模板 |
| 资源隔离 | 租户流量不互相争抢管道吞吐 | 限流队列、独立 worker 池、优先级调度 |
| 成本隔离 | 可追溯每个租户的资源消耗 | 租户标签计量、按租户拆分存储桶 |
1.3 OpenTelemetry 管道架构概览
OpenTelemetry 管道（Pipeline）是数据从采集到导出的核心路径。一个标准管道由三个基本组件构成：Receiver（接收器）、Processor（处理器）和 Exporter（导出器）。数据在管道中以 pdata（管道数据模型） 的形式流动。
1.4 管道中的服务边界：从单体到多租户
在单租户场景下，一个 Collector 实例即可完成所有工作。但在多租户场景中，我们需要在管道中明确划分服务边界：
- 物理边界：每个租户部署独立的 Collector 实例，完全隔离。
- 逻辑边界：共享 Collector 实例，通过租户 ID 标签在 Processor 中分流。
- 混合边界：核心管道共享（如 Receiver、基础 Processor），租户专属 Processor 和 Exporter 独立部署。
实践建议：在课程后续章节中，我们将深入分析每种边界模式的适用场景、性能开销和运维复杂度。对于大多数中大型组织，混合边界 是平衡隔离性与资源利用率的最佳起点。
1.5 课程路线图
本课程将围绕以下主线展开：
- 基础篇：OpenTelemetry Collector 配置语法、管道生命周期、数据模型。
- 隔离设计篇：标签注入策略、租户路由处理器、限流与背压机制。
- 架构实践篇：Kubernetes 环境下的多租户 Collector 部署、服务网格集成。
- 运维篇：租户级监控、成本计量、故障隔离与恢复。
每一章都会包含可运行的配置示例和架构决策分析，帮助你在实际项目中落地多租户隔离管道。