1. 可观测性基础概念：三大支柱与租户隔离
1.1 可观测性三大支柱的定义
可观测性（Observability）是衡量系统内部状态可通过外部输出被理解的程度。在分布式后端系统中，可观测性由三大数据支柱构成：Metrics（指标）、Logs（日志）、Traces（链路追踪）。三者各自独立又相互关联，共同构建完整的系统可观测视图。
| 支柱 | 定义 | 典型数据 | 主要用途 |
|---|---|---|---|
| Metrics | 可聚合的数值型时间序列数据，描述系统在某一时刻或时间段内的状态 | CPU 使用率、QPS、延迟 P99、错误率 | 实时监控、告警触发、容量规划 |
| Logs | 带时间戳的结构化或非结构化文本记录，描述系统发生的具体事件 | 访问日志、错误堆栈、业务操作记录 | 故障排查、审计追溯、详细分析 |
| Traces | 记录一次请求在分布式系统中经过的所有服务节点及调用关系 | Span ID、Trace ID、父 Span 引用、调用耗时 | 调用链分析、瓶颈定位、依赖关系梳理 |
核心认知：三大支柱不是替代关系，而是互补关系。Metrics 告诉你“系统出问题了”，Logs 告诉你“具体发生了什么错误”，Traces 告诉你“问题出在哪个环节”。
1.2 三大支柱的关系
三大支柱在数据层面存在天然的关联桥梁：Trace ID 可以嵌入 Logs 和 Metrics 的标签中，实现跨数据类型的关联查询。例如，当 Metrics 告警触发时，可通过时间窗口和标签快速定位到相关的 Trace 和 Logs。
实践要点：在日志采集端强制注入 Trace ID，在 Metrics 标签中保留 service.name 和 trace_id 字段，是实现三大支柱关联的基础工程手段。
1.3 为什么需要租户隔离
在多租户（Multi-Tenant）架构中，多个业务团队、客户或环境共享同一套可观测性基础设施。如果没有租户隔离，将面临以下严重问题：
- 数据安全风险：租户 A 的敏感业务数据可能被租户 B 通过查询接口或仪表盘意外访问。
- 性能干扰：一个租户的高流量写入可能导致存储后端 I/O 瓶颈，影响其他租户的查询响应。
- 资源争抢：缺乏配额控制时，单个租户可能耗尽索引资源、存储空间或查询并发额度。
- 成本分摊困难：无法准确统计每个租户的数据量、存储成本和查询消耗，导致计费不透明。
- 运维复杂度：全局共享的告警规则、仪表盘和保留策略无法满足不同租户的差异化需求。
| 维度 | 无隔离 | 有隔离 |
|---|---|---|
| 数据安全 | 租户间数据可交叉查询 | 严格数据边界，RBAC 控制 |
| 性能保障 | 共享资源池，无 QoS | 独立资源配额，限流降级 |
| 成本核算 | 全局账单，无法拆分 | 按租户计量，精确分摊 |
| 运维灵活性 | 统一配置，无法定制 | 租户级告警、保留策略、仪表盘 |
常见误区：租户隔离不等于物理隔离。在 SaaS 场景下，逻辑隔离（通过标签、索引分区、查询路由）往往比物理隔离更经济且易于运维。物理隔离仅在合规要求极高或性能隔离需求严苛时采用。
1.4 租户隔离的核心目标
设计可观测性租户隔离架构时，需要同时达成以下目标：
- 数据隔离：每个租户只能访问自己的 Metrics、Logs 和 Traces 数据。
- 性能隔离：一个租户的写入或查询负载不影响其他租户的可用性和响应时间。
- 资源隔离：为每个租户分配独立的存储配额、查询并发数和写入速率限制。
- 配置隔离：租户可独立管理告警规则、仪表盘、保留策略和索引模板。
- 计量隔离：精确统计每个租户的数据摄入量、存储量和查询次数，支持成本分摊。
设计原则：租户隔离应优先采用逻辑隔离 + 软配额方案，在保证隔离性的同时降低运维复杂度。仅在金融、医疗等强合规场景下，才考虑物理隔离或独立集群部署。