1. 可观测性基础：三大支柱与租户隔离的必要性
1.1 可观测性三大支柱：定义与关系
可观测性（Observability）是衡量系统内部状态可通过外部输出被理解的程度。在分布式后端架构中，业界普遍采用 Metrics（指标）、Logs（日志）、Traces（链路追踪） 三大支柱来构建可观测性体系。三者并非孤立存在，而是相互补充、协同工作。
| 支柱 | 定义 | 典型数据 | 主要用途 |
|---|---|---|---|
| Metrics | 可聚合的数值型时间序列数据，描述系统在某一时刻或时间段内的状态 | QPS、P99 延迟、CPU 使用率、错误率 | 实时监控、告警触发、容量规划、趋势分析 |
| Logs | 离散的、带时间戳的事件记录，描述系统在特定时间点发生的具体行为 | 请求日志、错误堆栈、审计日志、业务操作记录 | 故障排查、根因分析、审计合规、详细事件追溯 |
| Traces | 端到端的请求执行路径，记录请求在分布式系统中经过的每个服务及耗时 | Span 树、服务间调用关系、上下游延迟分布 | 性能瓶颈定位、依赖关系分析、分布式事务追踪 |
核心关系：Metrics 告诉你“系统出问题了”，Logs 告诉你“具体发生了什么错误”，Traces 告诉你“问题出在哪个环节以及为什么慢”。三者结合才能形成完整的可观测性闭环。
1.2 为什么需要租户隔离
在 SaaS 或多业务线架构中，多个租户（Tenant）共享同一套后端基础设施。如果可观测性数据不做租户隔离，将导致以下严重问题：
- 数据污染与误告警：一个租户的异常流量或错误日志会污染全局指标，引发针对其他租户的误告警。
- 安全与合规风险：租户 A 的敏感业务日志可能被租户 B 的运维人员看到，违反 GDPR、HIPAA 等合规要求。
- 排查效率低下：在海量混合数据中定位某个租户的具体问题，如同大海捞针，MTTR（平均修复时间）急剧上升。
- 成本归属不清：无法准确计算每个租户消耗的存储、计算和网络资源，导致成本分摊困难。
关键认知：租户隔离不是可观测性的附加功能，而是多租户架构下可观测性体系的基础前提。没有隔离，可观测性三大支柱的数据价值将大打折扣，甚至产生误导。
1.3 租户隔离的层次与策略
租户隔离可以在多个层次实施，不同层次对应不同的隔离粒度与成本。以下是常见的隔离策略对比：
| 隔离层次 | 实现方式 | 隔离粒度 | 运维复杂度 | 典型场景 |
|---|---|---|---|---|
| 物理/基础设施层 | 为每个租户部署独立的可观测性集群（如独立的 Prometheus、Elasticsearch） | 最高 | 高 | 金融、医疗等强合规行业 |
| 逻辑/数据层 | 共享集群，通过租户 ID 标签（Label/Tag）区分数据 | 中 | 低 | 大多数 SaaS 平台、内部多业务线 |
| 混合层 | 核心指标独立集群，日志和链路共享但严格打标 | 中高 | 中 | 大型互联网公司、混合云架构 |
实践建议：对于大多数后端团队，推荐从逻辑/数据层隔离起步。通过统一的租户 ID 标签体系，在 Metrics、Logs、Traces 中注入 tenant_id，即可在共享基础设施上实现高效的租户级数据隔离与查询。本课程后续章节将深入讲解如何通过结构化日志实现这一目标。
1.4 本章小结
- 可观测性三大支柱 Metrics、Logs、Traces 各有侧重，协同工作才能形成完整视图。
- 多租户架构下，租户隔离 是保障数据安全、提升排查效率、实现成本分摊的必要手段。
- 隔离策略需根据业务合规要求、团队运维能力和成本预算综合选择，逻辑隔离 是大多数场景的最佳起点。
- 下一章将深入 结构化日志 的设计原则，这是实现租户隔离的关键技术基础。