1. 课程导论：可观测性三大支柱与租户隔离基础
1.1 可观测性三大支柱概述
在分布式系统与微服务架构中，可观测性（Observability）是理解系统内部状态的关键能力。业界公认的三大支柱分别为：日志（Logs）、指标（Metrics） 和 链路追踪（Traces）。三者从不同维度提供系统运行视图，缺一不可。
| 支柱 | 核心定义 | 典型数据 | 主要用途 |
|---|---|---|---|
| 日志 | 离散、带时间戳的事件记录 | 错误栈、访问记录、业务操作 | 故障排查、审计、行为分析 |
| 指标 | 可聚合的数值型时间序列 | CPU 使用率、QPS、延迟分位数 | 告警、容量规划、趋势监控 |
| 链路追踪 | 请求在分布式系统中的完整路径 | Span ID、父 Span、耗时、服务名 | 性能瓶颈定位、依赖关系分析 |
关键认知： 三大支柱并非孤立存在。一条日志可以关联到某个 Trace 的 Span，一个指标异常可以通过 Trace 下钻到具体请求，再通过日志定位根因。可观测性的真正价值在于三者之间的 关联分析。
1.2 租户隔离在 SaaS 架构中的核心价值
在 SaaS 多租户架构中，租户隔离 是保障数据安全与服务质量的基础。可观测性系统作为基础设施的一部分，必须继承并强化这一隔离机制。若隔离不当，租户 A 的敏感日志可能被租户 B 看到，或租户 C 的突发流量导致全局告警风暴。
租户隔离的三个层次
- 数据隔离： 每个租户只能访问自己的日志、指标和链路数据。这是合规与安全的最低要求。
- 资源隔离： 避免“吵闹邻居”效应，防止一个租户的异常流量耗尽共享的可观测性存储或计算资源。
- 配置隔离： 告警规则、仪表盘、采样策略等可观测性配置应独立作用于每个租户。
| 隔离维度 | 无隔离风险 | 架构设计要点 |
|---|---|---|
| 数据隔离 | 跨租户数据泄露，违反 GDPR/SOC2 | 日志中嵌入 tenant_id，存储层按租户分区 |
| 资源隔离 | 单个租户流量洪峰导致全局写入阻塞 | 写入限流、独立索引、按租户配额管理 |
| 配置隔离 | 告警规则互相覆盖，仪表盘数据混乱 | 租户级命名空间，配置模板 + 租户覆盖 |
架构建议： 在可观测性系统设计初期就将 tenant_id 作为第一级分区键或标签。后期再添加隔离机制往往需要重构数据管道，成本极高。
1.3 结构化日志与可观测性的关系
传统非结构化日志（如纯文本字符串）难以被机器解析和关联。而 结构化日志 采用键值对或 JSON 格式，将日志内容拆分为可查询的字段，这是实现可观测性三大支柱关联的基石。
非结构化 vs 结构化日志对比
| 对比维度 | 非结构化日志 | 结构化日志 |
|---|---|---|
| 格式示例 | 2024-01-15 10:00:00 ERROR 订单处理失败 |
{"time":"2024-01-15T10:00:00Z","level":"ERROR","message":"订单处理失败","order_id":"12345","tenant_id":"t001"} |
| 可查询性 | 仅支持全文检索，精度低 | 支持按字段精确过滤、聚合分析 |
| 关联能力 | 无法自动关联 trace_id 或 metric | 天然携带 trace_id、span_id、tenant_id，可直接关联 |
| 租户隔离 | 需额外解析提取租户信息 | tenant_id 作为独立字段，隔离策略清晰 |
结构化日志的最佳实践
- 统一字段规范： 团队内约定必选字段（timestamp、level、message、service、tenant_id、trace_id），避免字段名歧义。
- 避免嵌套过深： 日志结构以 2~3 层为佳，过深嵌套会增加解析开销和查询复杂度。
- 上下文注入： 在服务入口处通过中间件自动注入 tenant_id 和 trace_id，确保日志链路完整。
- 日志级别合理使用： ERROR 用于需要立即关注的故障，WARN 用于潜在风险，INFO 用于关键业务流程，DEBUG 仅在开发环境开启。
常见陷阱： 很多团队在初期使用非结构化日志，后期再“打补丁”添加结构化字段。这会导致历史日志无法关联、查询性能低下。建议从项目第一天起就采用结构化日志格式，并纳入代码审查标准。