1. 课程导论：可观测性概述、Metric 在可观测性中的核心地位、为什么需要租户隔离
1.1 可观测性概述
可观测性（Observability）是衡量系统内部状态可通过其外部输出推断的程度。在云原生与微服务架构中，系统由数百个分布式组件构成，传统监控已无法应对其复杂性与动态性。可观测性通过三大数据支柱——指标（Metrics）、日志（Logs）、链路追踪（Traces）——提供对系统行为的全面洞察。
| 数据支柱 | 核心特征 | 典型用途 |
|---|---|---|
| Metrics | 数值型、可聚合、低存储成本 | 告警、容量规划、SLO 跟踪 |
| Logs | 文本型、结构化或非结构化、高信息密度 | 故障排查、审计、详细事件记录 |
| Traces | 请求级、端到端、上下文关联 | 延迟分析、依赖关系发现、性能瓶颈定位 |
核心认知：可观测性不是监控的替代品，而是监控的进化形态。监控回答“出了什么问题”，可观测性回答“为什么出问题”。
1.2 Metric 在可观测性中的核心地位
在三大支柱中，Metrics 处于最基础且最关键的层级。它提供系统健康度的量化视图，是告警、仪表盘、SLO 计算的直接数据源。Metrics 具有以下不可替代的优势：
- 低开销高密度：数值型数据占用存储少，可长期保留用于趋势分析。
- 实时聚合：支持秒级聚合与多维下钻，快速定位异常范围。
- 标准化生态：Prometheus、OpenTelemetry、StatsD 等工具链成熟，社区广泛采用。
- 告警基石：绝大多数生产告警规则基于 Metric 阈值或速率变化触发。
下图展示了 Metrics 在可观测性体系中的枢纽位置：
1.3 为什么需要租户隔离
在多租户环境中（如 SaaS 平台、内部 PaaS、混合云管理），不同团队、业务线或客户共享同一套基础设施与可观测性平台。若不对 Metric 数据进行租户隔离，将引发以下严重问题：
风险警示：缺乏租户隔离的 Metric 体系，本质上是一个“数据大锅饭”——任何租户的异常数据都可能污染全局视图，导致误告警、误判与安全泄露。
1.3.1 核心冲突：标签（Label）的命名与语义冲突
不同租户可能使用相同的 Metric 名称但含义不同，或使用相同的标签键但值格式不一致。例如：
- 命名冲突：租户 A 的
http_requests_total表示 API 网关请求，租户 B 的同一名称表示内部 RPC 调用。 - 标签键冲突：租户 A 用
env=prod表示生产环境，租户 B 用env=production表示同一含义。 - 标签值冲突：租户 A 的
service=payment指支付核心服务，租户 B 的service=payment指支付前端代理。
1.3.2 隔离的三大驱动力
| 驱动力 | 说明 | 后果（无隔离） |
|---|---|---|
| 数据安全与合规 | 租户的敏感业务指标不应被其他租户可见 | 数据泄露、违反 GDPR/SOC2 等合规要求 |
| 告警准确性 | 租户的告警规则应仅作用于自身数据 | 跨租户误告警、告警风暴、告警疲劳 |
| 成本分摊与配额 | 按租户统计 Metric 存储与查询量，实现公平计费 | 无法准确核算成本，资源滥用难以追溯 |
1.3.3 租户隔离的典型架构模式
下图展示了一种基于 标签前缀 + 元数据路由 的隔离方案，这是本课程后续章节将深入展开的核心模式：