1. 可观测性基础：可观测性三大支柱（Metrics、Logs、Traces）概念与关系
1.1 什么是可观测性
可观测性（Observability）源自控制理论，指通过系统外部输出来推断系统内部状态的能力。在云原生与微服务架构中，可观测性已成为运维与排障的核心方法论。一个系统具备可观测性，意味着工程师无需新增代码即可回答“系统当前发生了什么”、“为什么发生”、“影响范围多大”三类问题。
核心观点： 可观测性不是单一工具或平台，而是由 Metrics、Logs、Traces 三大数据支柱共同支撑的系统能力。三者缺一不可，相互补充。
1.2 三大支柱定义与特征
| 支柱 | 英文 | 核心定义 | 典型数据形态 | 主要用途 |
|---|---|---|---|---|
| 指标 | Metrics | 可聚合、可计算的数值型时间序列数据 | 计数器、直方图、仪表盘、摘要 | 监控告警、容量规划、趋势分析 |
| 日志 | Logs | 带时间戳的离散事件记录，通常为文本或结构化格式 | 单行文本、JSON 行、多行堆栈 | 详细排障、审计追溯、业务分析 |
| 链路 | Traces | 端到端请求在分布式系统中的完整调用路径 | Span 树、Trace ID + Span ID 链 | 性能瓶颈定位、依赖关系分析、错误传播追踪 |
1.3 三大支柱的关系模型
三大支柱并非孤立存在，而是通过公共标识符（如 Trace ID、Service Name、Timestamp）形成关联。下图展示了典型的关联场景：
1.4 三大支柱的对比分析
| 对比维度 | Metrics | Logs | Traces |
|---|---|---|---|
| 数据量级 | 低（聚合后恒定） | 高（随请求量线性增长） | 中（随请求量增长，但可采样） |
| 存储成本 | 低 | 高 | 中 |
| 查询延迟 | 毫秒级 | 秒级（需索引） | 秒级（需关联） |
| 排障深度 | 浅（仅知异常，不知原因） | 深（逐行查看上下文） | 深（完整调用路径） |
| 典型协议/标准 | Prometheus、StatsD、OpenMetrics | Syslog、JSON、ELK、Loki | OpenTelemetry、Jaeger、Zipkin |
1.5 三大支柱在 OpenTelemetry 中的统一
OpenTelemetry 是 CNCF 的观测性标准，其核心设计目标之一就是统一三大支柱的数据采集与关联。在 OpenTelemetry 中：
- Metrics 通过
MeterAPI 创建，支持 Counter、Histogram、UpDownCounter 等类型。 - Logs 通过
LoggerAPI 创建，支持结构化日志与自动关联 Trace 上下文。 - Traces 通过
TracerAPI 创建，Span 之间通过 Parent-Child 关系形成调用树。 - 三者共享 Resource（服务名、版本、环境）和 Context（Trace ID、Span ID）机制，天然关联。
工程要点： 在 OpenTelemetry SDK 埋点时，建议始终开启 Trace-Logs 关联（通过 Trace ID 注入日志上下文），以及 Metrics 与 Traces 的维度对齐（如使用相同的 Service Name 和 Attribute 命名规范）。这是实现“一键跳转”排障体验的基础。
1.6 三大支柱的典型协作流程
- 告警触发： Metrics 检测到 P99 延迟突增，触发告警通知。
- 日志定位： 工程师根据告警时间窗口，在 Logs 中搜索对应服务的 ERROR 级别日志，发现数据库连接超时。
- 链路分析： 从日志中提取 Trace ID，跳转到 Traces 查看完整调用链路，定位到具体慢 Span（如 SQL 查询耗时 5s）。
- 根因确认： 结合 Metrics 的数据库连接池指标，确认连接池耗尽导致排队等待。
常见误区： 不要只依赖单一支柱。仅看 Metrics 可能漏掉偶发错误；仅看 Logs 可能淹没在海量数据中；仅看 Traces 可能缺乏全局趋势。三大支柱协同使用才能实现高效排障。