1. 课程导论：什么是可观测性、为什么需要租户隔离、OTel在链路追踪中的角色
1.1 什么是可观测性
可观测性（Observability）源自控制理论，在云原生语境下指通过系统外部输出来推断内部状态的能力。与传统监控不同，可观测性不是被动地检查已知故障模式，而是允许工程师在未知问题发生时，通过数据探索来定位根因。
可观测性的三大支柱（Three Pillars）构成了现代可观测性体系的基石：
| 支柱 | 定义 | 典型数据 | 核心价值 |
|---|---|---|---|
| 指标（Metrics） | 可聚合的数值型时间序列数据 | 请求延迟、CPU使用率、错误率 | 趋势分析与告警 |
| 日志（Logs） | 带时间戳的离散事件记录 | 应用日志、系统日志、审计日志 | 详细上下文与调试 |
| 链路追踪（Traces） | 端到端请求路径的分布式记录 | Span、Trace ID、服务依赖图 | 请求级性能分析与故障定位 |
关键认知： 三大支柱并非孤立存在。在云原生架构中，链路追踪是连接指标与日志的桥梁——通过 Trace ID 可以关联到具体的 Metrics 异常和 Logs 上下文，形成完整的可观测性闭环。
1.2 为什么需要租户隔离
在多租户（Multi-Tenant）云原生环境中，多个团队、业务线或客户共享同一套基础设施和可观测性平台。如果没有有效的租户隔离，将面临以下严重问题：
- 数据泄露风险： 租户 A 的敏感业务数据可能被租户 B 意外访问。
- 性能干扰： 一个租户的高流量或异常数据可能影响其他租户的查询性能。
- 成本归属模糊： 无法准确核算每个租户的可观测性资源消耗。
- 合规性挑战： 金融、医疗等行业要求严格的数据边界和审计隔离。
实战经验： 在大型 SaaS 平台中，租户隔离不仅是安全需求，更是运维效率需求。没有隔离的链路追踪系统，当故障发生时，运维人员需要从海量跨租户数据中手动过滤，平均故障定位时间（MTTR）会延长 3-5 倍。
租户隔离在链路追踪中的核心目标可以概括为以下三个层次：
| 隔离层次 | 目标 | 实现方式 |
|---|---|---|
| 数据隔离 | 租户只能看到自己的 Trace 数据 | 租户标签、数据分区、访问控制 |
| 性能隔离 | 租户间数据采集和查询互不干扰 | 采样率独立配置、存储资源池化 |
| 成本隔离 | 精确计量每个租户的可观测性成本 | 租户级标签、用量统计、计费分摊 |
1.3 OTel在链路追踪中的角色
OpenTelemetry（OTel）是 CNCF 孵化的可观测性标准，它解决了传统链路追踪领域的碎片化问题。在链路追踪中，OTel 扮演了以下关键角色：
- 统一数据模型： 定义标准的 Span、Trace、Resource 数据结构，消除厂商锁定。
- 跨语言 SDK： 提供 Java、Go、Python、Node.js 等主流语言的自动/手动埋点能力。
- 采集与处理管道： OTel Collector 作为独立组件，负责接收、处理、导出 Trace 数据。
- 上下文传播： 通过 W3C TraceContext 标准，实现跨服务、跨协议的 Trace ID 传递。
- 租户标签注入： 在数据采集阶段自动注入租户标识，为隔离提供数据基础。
常见误区： OTel 本身不提供存储和可视化能力。它负责数据的生成、采集、处理、导出，而存储和展示需要对接 Jaeger、Zipkin、Grafana Tempo、Datadog 等后端系统。理解这个边界对于设计租户隔离方案至关重要。
OTel 在链路追踪中的完整数据流如下：
- 应用埋点： 通过 OTel SDK 在服务中生成 Span，携带 Trace ID、Span ID、租户标签。
- 上下文传播： 通过 HTTP/gRPC 请求头传递 Trace 上下文，保证跨服务链路完整。
- 数据导出： SDK 将 Span 数据发送到 OTel Collector（gRPC/HTTP 协议）。
- 数据处理： Collector 进行批处理、过滤、采样、租户标签增强。
- 数据导出： Collector 将处理后的数据写入后端存储系统。
1.4 本章小结
核心要点回顾：
- 可观测性通过指标、日志、链路追踪三大支柱实现系统内部状态推断，链路追踪是连接其他支柱的桥梁。
- 多租户环境下，数据隔离、性能隔离、成本隔离是链路追踪必须解决的三大挑战。
- OTel 作为统一标准，在链路追踪中负责数据生成、采集、处理、导出，并通过租户标签机制为隔离提供基础。
- 本课程后续章节将深入 OTel SDK 埋点、Collector 配置、租户标签策略、存储隔离等实战内容。