1. 可观测性概述：三大支柱与租户隔离的必要性
1.1 可观测性的定义与核心价值
在分布式系统架构中，可观测性（Observability）是指通过系统外部输出的数据（指标、日志、链路），推断系统内部状态的能力。它不同于传统的监控——监控回答“系统是否挂了”，可观测性回答“系统为什么挂了”。
核心公式：可观测性 = Metrics（指标）+ Logs（日志）+ Traces（链路） + 上下文关联能力
1.2 三大支柱的定义与关系
可观测性由三大数据支柱构成，它们各自解决不同维度的问题，又通过关联形成完整视图：
| 支柱 | 英文 | 定义 | 典型数据 | 回答的问题 |
|---|---|---|---|---|
| 指标 | Metrics | 系统在时间维度上的聚合数值，可计数、可求和、可求平均 | QPS、P99延迟、CPU使用率、错误率 | 系统当前状态如何？趋势是否异常？ |
| 日志 | Logs | 系统在特定时间点产生的离散事件记录，带时间戳和结构化/非结构化文本 | 错误堆栈、访问日志、业务操作记录 | 具体发生了什么？错误详情是什么？ |
| 链路 | Traces | 一次请求在分布式系统中经过的所有服务、组件和操作的完整路径 | Span ID、Trace ID、服务间调用耗时 | 请求慢在哪里？哪个服务是瓶颈？ |
三大支柱并非孤立存在，它们之间存在天然的关联关系：
- 指标触发告警 → 通过日志定位具体错误 → 通过链路追踪找到故障服务。
- 链路中的每个 Span 可以关联该服务节点的指标（如 CPU、内存）和该时间点的日志。
- 统一关联标识（如 Trace ID、Service Name、Timestamp）是打通三大支柱的关键。
1.3 为什么需要租户隔离
在单租户场景下，可观测性数据属于同一业务系统，不存在数据边界问题。但在多租户架构中，多个客户（租户）共享同一套基础设施和可观测性平台，此时必须引入租户隔离机制。核心原因如下：
| 维度 | 问题描述 | 不隔离的后果 |
|---|---|---|
| 数据安全 | 租户 A 的日志、指标、链路数据可能被租户 B 看到 | 违反合规要求（GDPR、等保）、商业机密泄露 |
| 性能干扰 | 一个租户的突发流量导致可观测性系统过载，影响其他租户 | 告警延迟、数据丢失、查询超时 |
| 成本归属 | 无法准确区分每个租户的可观测性资源消耗 | 成本无法分摊、计费不透明 |
| 查询隔离 | 租户 A 的查询操作可能占用大量资源，拖慢租户 B 的查询 | 查询体验不一致、SLA 无法保障 |
| 配置管理 | 不同租户的告警规则、采样策略、保留周期不同 | 配置冲突、运维混乱 |
关键认知：租户隔离不是可观测性系统的可选功能，而是多租户场景下的强制性架构约束。隔离的粒度、层级和实现方式直接影响系统的安全性、性能和运维复杂度。
1.4 租户隔离的三种典型模式
根据隔离的深度和资源复用程度，租户隔离通常分为以下三种模式：
- 完全物理隔离（Hard Multi-Tenancy）：每个租户部署独立的可观测性组件实例（如独立的 Prometheus、Elasticsearch 集群）。安全性最高，但资源利用率低、运维成本高。
- 逻辑隔离（Soft Multi-Tenancy）：共享同一套可观测性基础设施，但通过数据标签（如
tenant_id）、索引分区、命名空间等方式实现数据隔离。资源利用率高，但隔离强度依赖实现质量。 - 混合隔离（Hybrid Multi-Tenancy）：核心敏感数据使用物理隔离，非敏感数据使用逻辑隔离。兼顾安全与成本，是大型 SaaS 平台的常见选择。
1.5 本章小结
可观测性三大支柱（Metrics、Logs、Traces）共同构成了分布式系统的“感知神经”。在多租户场景下，租户隔离是保障数据安全、性能稳定、成本可控和运维有序的基石。本章为后续深入探讨隔离架构设计、通信机制和工程实践奠定了理论基础。
实践提示：在开始设计租户隔离方案前，建议先梳理业务场景中的租户数量、数据敏感等级、合规要求和预算约束，这将直接影响隔离模式的选择。