可观测Mock隔离OTelMock隔离 - 第1节
1.1 可观测性的核心定义
可观测性（Observability）源自控制理论，指通过系统外部输出来推断内部状态的能力。在软件工程领域，可观测性意味着通过收集和分析系统产生的数据，无需新增代码即可理解系统行为、定位故障根因。
现代可观测性体系建立在三大支柱之上：指标（Metrics）、日志（Logs） 和 链路追踪（Traces）。三者并非孤立存在，而是相互补充、协同工作，共同构建完整的系统可观测视图。
核心认知： 可观测性 ≠ 监控。监控告诉你系统“是否”出问题，可观测性告诉你系统“为什么”出问题。三大支柱的融合是实现真正可观测性的关键。
1.2 三大支柱的定义与特征
1.2.1 指标（Metrics）
指标是系统在特定时间点或时间窗口内的数值聚合数据，具有可聚合、低存储成本、高查询效率的特点。指标通常用于告警、趋势分析和容量规划。
| 特征 | 说明 | 示例 |
|---|---|---|
| 聚合性 | 可对多个实例的数据进行求和、平均、分位数计算 | 所有 Pod 的 CPU 使用率平均值 |
| 时间序列 | 按时间戳存储，支持降采样和长期保留 | 每分钟的请求延迟 P99 |
| 低基数 | 维度组合数量有限，适合快速查询 | HTTP 状态码（200/404/500） |
| 预定义 | 需要提前定义指标名称和标签 | http_requests_total{method="GET"} |
1.2.2 日志（Logs）
日志是系统在特定时间点发生的离散事件的文本记录，包含时间戳、严重级别、事件描述等字段。日志提供最丰富的上下文信息，是故障排查时最常查阅的数据源。
| 特征 | 说明 | 示例 |
|---|---|---|
| 非结构化/半结构化 | 自由文本或 JSON 格式，灵活但解析成本高 | 2025-01-15 10:30:00 ERROR DB connection timeout |
| 高基数 | 每条日志唯一，维度无限 | 每个请求的 trace_id 和 span_id |
| 存储成本高 | 需要压缩、索引和生命周期管理 | 每天 TB 级别的日志量 |
| 事后分析 | 主要用于问题发生后的根因定位 | 搜索特定 trace_id 的所有日志 |
1.2.3 链路追踪（Traces）
链路追踪记录一个请求在分布式系统中经过的所有服务、组件和操作的完整路径。每个追踪由多个 Span 组成，Span 之间通过父-子关系形成调用树。
| 特征 | 说明 | 示例 |
|---|---|---|
| 请求级 | 以单个请求为粒度，记录端到端路径 | 用户下单请求经过 Gateway → Order → Payment |
| 上下文传播 | 通过 Trace ID 和 Span ID 跨服务传递 | HTTP Header 中的 traceparent |
| 时序关系 | 精确记录每个 Span 的开始时间和持续时间 | Span A 耗时 200ms，Span B 耗时 150ms |
| 依赖分析 | 可生成服务依赖图和调用拓扑 | 识别出哪个下游服务导致整体延迟增加 |
1.3 三大支柱的关系与协同
三大支柱并非替代关系，而是互补关系。指标提供“是什么”的宏观视图，日志提供“是什么”的详细证据，链路追踪提供“为什么”的路径分析。三者结合才能形成完整的可观测性闭环。
经典协同场景：
1. 指标告警触发：
1. 指标告警触发：
error_rate > 5% → 查看对应时间段的日志 → 发现大量 DB timeout 错误 → 通过 Trace ID 追踪到具体请求路径 → 定位到数据库连接池耗尽的服务实例。
1.4 三大支柱的对比总结
| 维度 | 指标（Metrics） | 日志（Logs） | 链路追踪（Traces） |
|---|---|---|---|
| 数据形态 | 数值聚合 | 文本事件 | Span 树结构 |
| 粒度 | 时间窗口聚合 | 单条事件 | 单个请求 |
| 存储成本 | 低 | 高 | 中 |
| 查询效率 | 极高 | 中（需索引） | 高（按 Trace ID） |
| 主要用途 | 告警、趋势、容量 | 根因分析、审计 | 性能瓶颈、依赖分析 |
| 典型工具 | Prometheus, Grafana | ELK, Loki | Jaeger, Zipkin |
| OpenTelemetry 支持 | Meter API | Logger API | Tracer API |
1.5 从监控到可观测性的演进
传统监控关注已知故障模式，通过预定义阈值触发告警。可观测性则强调探索未知问题，通过多维数据关联发现系统行为的异常模式。
常见误区： 不要将三大支柱割裂使用。只收集指标而忽略日志和链路追踪，会导致“知道系统出问题，但不知道哪里出问题”的困境。反之，只有日志没有指标，则难以建立全局视图和有效告警。
1.6 OpenTelemetry 的统一视角
OpenTelemetry 作为 CNCF 的观测性标准，提供了统一的 API 和 SDK 来生成三大支柱数据。它通过以下方式实现数据关联：
- 上下文传播： Trace ID 和 Span ID 自动注入到日志和指标中，实现跨数据源关联。
- 统一语义约定： 定义通用的属性命名规范，确保不同服务的数据格式一致。
- 多信号导出： 同一套代码同时生成 Metrics、Logs 和 Traces，无需分别接入不同 SDK。
实战要点： 在 OpenTelemetry 中，三大支柱通过
Context 对象天然关联。例如，一个 Span 可以记录日志事件（span.AddEvent），也可以关联指标（meter.Record 时传入 Context）。这种设计使得从指标告警到日志查询再到链路追踪的跳转变得无缝。