OTel可观测租户隔离链路追踪 - 第1节
1.1 什么是可观测性
可观测性（Observability）源自控制理论，在云原生语境下，指通过系统外部输出推断内部状态的能力。一个系统是否可观测，取决于运维人员能否在不发布新代码的前提下，回答“系统为什么现在处于这个状态”。
在分布式架构中，可观测性通常由三大支柱构成：
| 支柱 | 核心作用 | 典型数据 |
|---|---|---|
| 指标（Metrics） | 聚合统计，反映系统健康趋势 | 请求延迟 P99、CPU 使用率、错误率 |
| 日志（Logs） | 离散事件记录，提供故障现场细节 | 错误堆栈、访问日志、审计记录 |
| 链路追踪（Traces） | 端到端请求流，定位性能瓶颈与依赖关系 | Span 树、调用耗时、上下游服务拓扑 |
核心观点：三大支柱并非孤立存在。可观测性的真正价值在于将指标、日志、追踪关联起来——例如从高延迟指标下钻到具体 Trace，再关联对应日志，形成完整的故障排查闭环。
1.2 为什么需要租户隔离
在 SaaS 或多业务线架构中，多个租户共享同一套基础设施和可观测性平台。如果没有隔离，会出现以下问题：
- 数据泄露风险：租户 A 的调用链可能被租户 B 看到，违反合规要求。
- 性能干扰：一个租户的突发流量导致全平台追踪采样率下降，影响其他租户。
- 成本归属不清：无法区分每个租户产生的 Span 数量、存储用量和查询开销。
- 告警噪音：全局告警规则无法适配不同租户的差异化阈值。
租户隔离的目标是在共享基础设施上实现逻辑隔离，确保每个租户只能访问自己的可观测性数据，同时保持平台的整体运维效率。
隔离粒度对比：
| 隔离方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 物理隔离（独立集群） | 最强安全，无性能干扰 | 成本高，运维复杂 | 金融、医疗等强合规行业 |
| 逻辑隔离（标签/属性） | 成本低，弹性好 | 需严格权限控制 | 大多数 SaaS 平台 |
| 混合隔离（物理+逻辑） | 兼顾安全与成本 | 架构复杂度高 | 大型多租户平台 |
1.3 OTel 在链路追踪中的角色
OpenTelemetry（OTel）是 CNCF 的毕业项目，提供一套厂商中立的数据采集、处理、导出标准。在链路追踪领域，OTel 扮演以下关键角色：
- 统一数据模型：定义 Span、Trace、SpanContext 等核心结构，消除厂商锁定。
- 多语言 SDK：支持 Java、Go、Python、Node.js 等主流语言，自动或手动注入追踪上下文。
- 传播机制：通过 W3C TraceContext 标准，在服务间传递 TraceId、SpanId 和租户属性。
- 处理器与导出器：支持采样、过滤、批处理，并将数据导出到 Jaeger、Zipkin、Prometheus 等后端。
- 资源与属性：通过 Resource 和 Span Attributes 携带租户标识，实现数据隔离。
下图展示了 OTel 在典型微服务链路追踪中的位置：
关键设计原则：租户隔离不是 OTel 的默认行为，而是通过 Resource 属性、Span Attributes 和 Collector 配置组合实现的。本课程后续章节将逐一拆解这些配置细节。
1.4 课程核心目标
通过本课程，你将掌握以下能力：
- 理解 OTel 链路追踪的数据模型与传播机制
- 设计多租户场景下的 Trace 属性规范
- 配置 OTel Collector 实现租户级数据路由与采样
- 在 Jaeger、Grafana Tempo 等后端实现租户隔离查询
- 构建跨服务、跨租户的端到端追踪可观测性