1. 可观测性概述：三大支柱与租户隔离的必要性
1.1 可观测性的定义与核心价值
在云原生与微服务架构中，可观测性（Observability）是指通过系统外部输出的数据，推断系统内部状态的能力。它并非单一工具或指标，而是一种工程实践，旨在让运维与开发团队在无需新增代码的情况下，快速定位故障根因、评估性能瓶颈、理解用户行为。
可观测性的核心价值体现在三个层面：
- 故障快速定位：从告警到根因分析的时间从小时级压缩到分钟级。
- 容量与性能优化：基于真实流量数据指导资源扩缩容与代码调优。
- 服务等级协议（SLA）保障：量化系统健康度，驱动持续改进。
1.2 可观测性三大支柱：Metrics、Logs、Traces
业界公认的可观测性数据模型由 Metrics（指标）、Logs（日志）、Traces（链路追踪） 三大支柱构成。三者并非孤立，而是相互补充、协同工作。
| 支柱 | 定义 | 典型数据 | 主要用途 | 存储特点 |
|---|---|---|---|---|
| Metrics | 可聚合的数值型时间序列数据 | CPU 使用率、请求 QPS、错误率、P99 延迟 | 实时监控、告警触发、趋势分析 | 高压缩率，保留时间长 |
| Logs | 离散的、带时间戳的事件记录 | 应用日志、访问日志、错误堆栈 | 根因分析、审计、调试 | 数据量大，需索引与归档策略 |
| Traces | 端到端请求路径的分布式追踪 | Span 列表、服务间调用关系、耗时分布 | 依赖分析、性能瓶颈定位、拓扑发现 | 采样率高时存储成本大 |
1.3 三大支柱的关系：从信号到洞察
三大支柱并非平行独立，而是形成一条从宏观到微观的关联链路：
- Metrics 提供“是什么”：通过仪表盘发现某个服务错误率飙升。
- Traces 提供“在哪里”：通过链路追踪定位到具体哪个接口、哪个下游服务出现异常。
- Logs 提供“为什么”：通过该 Trace 关联的日志详情，找到具体的异常堆栈或错误参数。
实践要点：在租户隔离场景中，三大支柱必须共享同一个租户标识（如 tenant_id），才能实现跨信号的关联分析。否则，即使每个信号都独立隔离，也无法在故障排查时形成完整视图。
1.4 为什么需要租户隔离
在 SaaS 平台、多业务线共享集群或混合云环境中，多个租户（团队、客户、业务线）共享同一套可观测性基础设施。如果没有有效的租户隔离，将引发以下问题：
| 问题类别 | 具体表现 | 后果 |
|---|---|---|
| 数据安全 | 租户 A 的敏感日志被租户 B 查询到 | 合规风险、数据泄露 |
| 性能干扰 | 租户 C 的大查询导致整个 Elasticsearch 集群负载飙升 | 影响所有租户的查询响应时间 |
| 成本归属 | 无法区分各租户的存储与计算资源消耗 | 成本分摊混乱，无法做精细化计费 |
| 告警噪音 | 租户 D 的测试环境告警干扰生产环境值班人员 | 告警疲劳，重要告警被淹没 |
| 配置冲突 | 不同租户对采样率、保留周期的需求不同 | 全局配置无法满足个性化需求 |
常见误区：很多团队认为只要在数据中增加一个 tenant_id 字段就完成了隔离。实际上，真正的租户隔离需要覆盖数据写入、存储分区、查询权限、资源配额、告警路由、成本核算等全链路，而不仅仅是逻辑标签。
1.5 租户隔离的层次模型
根据隔离的严格程度与实现成本，租户隔离通常分为三个层次：
- L1 - 逻辑隔离（软隔离）：共享同一套存储与计算资源，通过标签（如 tenant_id）区分数据。实现简单，但存在性能干扰与安全风险。
- L2 - 资源隔离（硬隔离）：为每个租户分配独立的索引、Topic 或数据库实例，但共享集群管理面。安全性提升，成本可控。
- L3 - 物理隔离：每个租户拥有独立的可观测性集群（如独立的 Prometheus + Grafana + Jaeger）。安全性最高，但资源利用率低、运维成本高。