1. 课程导论：多租户可观测性的定义、挑战与价值，OpenTelemetry 项目简介
1.1 什么是多租户可观测性？
多租户可观测性是指在同一个可观测性平台或基础设施中，同时为多个独立租户（如业务线、客户、团队或环境）提供 指标（Metrics）、日志（Logs） 和 链路追踪（Traces） 的采集、存储、分析与告警能力，并确保每个租户的数据在逻辑或物理上完全隔离。
其核心特征包括：
- 数据隔离：租户 A 的遥测数据不可被租户 B 访问。
- 资源配额：每个租户消耗的采集、存储、查询资源受控且可计量。
- 统一治理：共享底层管道，但策略（采样、保留、告警）可独立配置。
- 成本分摊：能够将基础设施成本精确归因到每个租户。
关键区分： 多租户 ≠ 多环境。多环境（如 dev/staging/prod）通常由同一团队管理，数据可以交叉引用；多租户则强调数据主权与安全边界，常见于 SaaS 平台、云服务商或大型企业内部共享服务场景。
1.2 多租户可观测性的核心挑战
构建多租户可观测性并非简单地在现有系统上加一个“租户 ID”字段。下表总结了主要挑战及其影响：
| 挑战维度 | 具体问题 | 典型后果 |
|---|---|---|
| 数据隔离 | 共享存储后端（如 Elasticsearch、ClickHouse）中，租户数据混合存放，查询时需严格过滤。 | 查询性能下降，误越权风险高，合规审计困难。 |
| 采样策略冲突 | 头部采样（Head-based Sampling）无法感知租户维度，导致低流量租户被完全丢弃。 | 关键业务链路丢失，排障盲区扩大。 |
| 资源噪声 | 一个租户的突发流量（如 DDoS 或异常任务）可能耗尽共享 Collector 或存储 IO。 | 全局服务质量（QoS）下降，无辜租户被牵连。 |
| 成本归因 | 遥测数据经过多层管道（Agent → Collector → Backend），租户标签在传输中丢失或变形。 | 无法准确计算每个租户的可观测性成本，财务对账混乱。 |
| 配置复杂度 | 每个租户可能需要不同的采样率、保留周期、告警规则和仪表盘。 | 运维人员陷入配置泥潭，变更风险高。 |
常见误区： 很多团队初期只在 Metrics 上增加一个
tenant_id 标签，却忽略了 Traces 和 Logs 的隔离。当需要排查跨租户的依赖故障时，才发现链路数据完全混杂，无法追溯。
1.3 多租户可观测性的业务价值
投入资源解决上述挑战，能够带来明确的商业与技术回报：
- 提升客户信任：SaaS 客户要求自己的监控数据严格隔离，这是合规（如 SOC2、GDPR）的基础。
- 降低平均修复时间（MTTR）：租户维度的关联分析让 SRE 团队能快速定位“哪个租户的哪个服务”出了问题，而非在全局噪声中大海捞针。
- 优化基础设施成本：通过租户级资源消耗报表，推动业务团队优化自身代码，减少无效遥测数据产生。
- 支撑精细化运营：产品团队可以根据租户的黄金信号（延迟、流量、错误、饱和度）制定差异化的 SLA 保障方案。
1.4 OpenTelemetry 项目简介
OpenTelemetry（简称 OTel） 是 CNCF 的毕业项目，旨在提供一套与厂商无关、标准化的遥测数据采集、处理和导出框架。它统一了 Metrics、Logs 和 Traces 三大信号的生产与传输协议，是目前可观测性领域的事实标准。
其核心组件包括：
- API：定义如何产生遥测数据（如 Tracer、Meter、Logger）。
- SDK：实现 API，提供采样、上下文传播、批处理等能力。
- Collector：独立的代理服务，负责接收、处理、导出遥测数据，支持灵活的 Pipeline 配置。
- Exporter：将数据发送到后端（如 Prometheus、Jaeger、Loki、Datadog）。
- Instrumentation：为常见框架（Spring Boot、Express、gRPC 等）提供自动埋点库。
下图展示了 OpenTelemetry 在单租户场景下的标准数据流：
1.5 为什么 OpenTelemetry 是多租户架构的理想基座？
OpenTelemetry 的设计天然支持多租户扩展，主要体现在以下方面：
| OTel 特性 | 多租户价值 |
|---|---|
| 上下文传播（Context Propagation） | 租户 ID 可以作为 W3C Trace Context 的扩展属性，自动在服务间传递，无需手动透传。 |
| Collector Pipeline 可编程 | 通过 Processor 组件（如 Attributes Processor、Filter Processor）动态注入、修改或路由租户标签。 |
| OTLP 协议的可扩展性 | 支持自定义 Resource 属性，可将 tenant.id、tenant.name 等元数据附加到每个遥测信号。 |
| 多 Exporter 支持 | 同一 Collector 实例可将不同租户的数据导出到不同的后端索引或表空间。 |
| 采样决策的灵活性 | 支持尾部采样（Tail-based Sampling），可根据租户 ID 等属性做差异化采样策略。 |
实践建议： 在 OTel SDK 初始化时，通过
Resource API 将租户信息作为资源属性注入。这样所有从该服务发出的遥测数据都会自动携带租户上下文，避免在业务代码中手动添加标签。
1.6 本课程的核心内容预览
本课程将围绕以下主线展开：
- 数据建模：如何设计租户维度的 Resource 属性与 Span 属性。
- Collector 架构：部署模式（Sidecar/Proxy/Gateway）、Pipeline 隔离策略。
- 采样策略：基于租户优先级的头部采样与尾部采样实现。
- 存储隔离：Elasticsearch 索引模式、ClickHouse 表引擎选择、Prometheus 多租户方案。
- 成本与治理：租户级用量计量、配额控制、审计日志。
- 实战案例：基于 OTel 构建一个支持 100+ 租户的 SaaS 可观测性平台。
通过本课程，你将掌握从理论到代码的完整多租户可观测性建设方法，能够直接应用于生产环境。