2. 可观测性基础：Metrics、Logs、Traces 三大支柱的定义与关系
可观测性（Observability）是 SRE 从“已知故障响应”走向“未知问题发现”的核心能力。它并非单一工具，而是通过三类遥测数据——Metrics（指标）、Logs（日志）、Traces（链路）——对系统内部状态进行推断与控制。这三类数据被称为“可观测性三大支柱”，彼此互补，缺一不可。
2.1 三大支柱的定义
| 支柱 | 定义 | 典型数据 | 查询方式 |
|---|---|---|---|
| Metrics | 可聚合的数值时间序列，描述系统在某一时刻或时段的状态 | CPU 使用率、请求 QPS、错误率、P99 延迟 | PromQL、Graphite、SQL 聚合 |
| Logs | 带时间戳的离散事件记录，描述系统发生了什么 | 应用日志、系统日志、审计日志、异常堆栈 | 全文检索、结构化查询（Loki、Elasticsearch） |
| Traces | 端到端请求的调用链路，描述请求在分布式系统中的完整路径 | Span ID、Trace ID、父 Span、服务间调用耗时 | TraceID 检索、服务拓扑图、火焰图 |
SRE 视角：Metrics 回答“系统是否健康”，Logs 回答“具体哪里出错了”，Traces 回答“请求到底经历了什么”。三者结合才能形成完整的故障定位闭环。
2.2 三大支柱的关系
三大支柱并非孤立存在，而是通过关联标识符（如 TraceID、ServiceName、Timestamp）形成数据关联。下图展示了在典型微服务架构中，三类数据如何协同工作：
关联示例：当 Metrics 显示 P99 延迟飙升时，SRE 可通过 TraceID 找到对应慢请求的完整调用链路，再通过链路中的 Span 关联到具体服务的错误日志，从而快速定位根因。
2.3 OpenTelemetry 在三大支柱中的角色
OpenTelemetry（OTel） 是 CNCF 孵化的可观测性标准框架，旨在统一三大支柱的数据采集、处理与导出规范。它并非一个完整的后端存储或可视化平台，而是充当“数据采集层”的标准化中间件。
2.3.1 OpenTelemetry 的核心能力
- 统一 API 与 SDK：提供多语言（Go、Python、Java 等）的标准化 API，开发者只需引入 OTel SDK 即可生成 Metrics、Logs、Traces。
- 自动插桩：通过 Agent 或库自动捕获常见框架（HTTP、gRPC、数据库、消息队列）的遥测数据，无需手动埋点。
- 关联上下文传播：通过 W3C TraceContext 标准，自动在服务间传递 TraceID、SpanID，实现跨服务链路关联。
- 灵活的导出器（Exporter）：支持将数据导出到 Prometheus、Jaeger、Zipkin、Loki、Datadog、AWS X-Ray 等数十种后端。
2.3.2 OpenTelemetry 架构图
2.3.3 三大支柱与 OTel 的映射
| 支柱 | OTel 数据模型 | 典型导出目标 | Runbook 联动场景 |
|---|---|---|---|
| Metrics | Metric 数据点（Counter、Gauge、Histogram） | Prometheus、VictoriaMetrics | 指标告警触发 Runbook |
| Logs | LogRecord（时间戳、Body、Attributes） | Loki、Elasticsearch、Splunk | 日志上下文注入 Runbook |
| Traces | Span（TraceID、SpanID、ParentSpanID、Duration） | Jaeger、Tempo、Zipkin | 链路拓扑嵌入 Runbook |
常见误区：OpenTelemetry 不是“可观测性平台”，而是“数据采集标准”。它不提供仪表盘、告警规则或长期存储。你需要搭配 Prometheus、Jaeger、Loki 等后端才能构建完整的可观测性体系。
2.4 三大支柱在 Runbook 中的联动价值
在《Runbook 联动 OpenTelemetry 实现故障闭环》课程中，三大支柱的联动是 Runbook 自动化的数据基础：
- Metrics 驱动告警：当 Metrics 触发告警（如 P99 延迟 > 500ms），Runbook 自动启动。
- Traces 定位瓶颈：Runbook 通过 TraceID 获取慢请求的完整调用链，识别瓶颈服务。
- Logs 提供根因：Runbook 自动拉取瓶颈服务的错误日志，分析异常堆栈。
- 自动修复与验证：Runbook 执行修复操作后，再次查询 Metrics 确认恢复。