1. 可观测性基础：三大支柱与日志-链路关联
1.1 可观测性三大支柱的定义与关系
在云原生与微服务架构中，可观测性（Observability）是理解系统内部状态的关键能力。业界公认的三大支柱为：日志（Logs）、指标（Metrics）和链路（Traces）。三者并非孤立存在，而是从不同维度共同构建系统的可观测视图。
| 支柱 | 定义 | 典型数据 | 核心价值 |
|---|---|---|---|
| 日志 | 离散的、带时间戳的事件记录，描述系统在某一时刻发生了什么 | 错误堆栈、访问日志、业务操作记录 | 细粒度排查、根因定位、审计追溯 |
| 指标 | 可聚合的、数值型的时间序列数据，反映系统状态与趋势 | CPU 使用率、请求延迟 P99、QPS | 监控告警、容量规划、趋势分析 |
| 链路 | 端到端的请求追踪，记录请求在分布式系统中的完整调用路径 | Span 列表、服务依赖图、耗时分布 | 性能瓶颈识别、依赖关系可视化、跨服务问题定位 |
核心关系：三大支柱是互补的“三棱镜”——日志回答“发生了什么”，指标回答“是否异常”，链路回答“哪里出了问题”。单独使用任一维度都会导致可观测性盲区。
1.2 为什么需要将日志与链路关联
在实际运维与排障场景中，日志和链路长期处于“各自为政”的状态：日志系统记录了海量事件，但缺乏请求维度的上下文；链路系统展示了调用拓扑，但缺少详细的错误堆栈与业务日志。这种割裂导致以下痛点：
- 排障效率低：发现一个慢 Trace，却无法快速找到对应的应用日志来确认具体错误原因。
- 上下文丢失：日志中记录了错误，但无法回溯该错误属于哪个请求、经过了哪些服务。
- 根因定位困难：指标告警触发后，需要人工在日志和链路系统之间反复切换，手动关联 TraceID 与日志标签。
- 数据孤岛：日志、指标、链路存储在不同的后端，缺乏统一的关联查询入口。
关键洞察：将日志与链路关联的核心在于——在日志中注入链路上下文（TraceID / SpanID），使得每条日志都能追溯到所属的请求链路。这是打通可观测性三大支柱的“第一公里”。
1.3 关联的技术实现路径
将日志与链路关联，通常遵循以下技术路径：
- 注入链路上下文：在服务入口处（如 API 网关、服务网格 Sidecar）生成 TraceID，并通过 OpenTelemetry SDK 将其传播到所有下游服务。
- 日志中携带 TraceID：在日志框架（如 Logback、Log4j2）中配置 MDC（Mapped Diagnostic Context），自动将当前 TraceID 和 SpanID 注入到每条日志中。
- 统一存储与索引：将携带 TraceID 的日志发送到 Loki，并将 TraceID 作为 Loki 的标签（Label）进行索引。
- 关联查询：在 Grafana 中通过 Loki 数据源查询日志，再通过 TraceID 跳转到 Tempo 或 Jaeger 查看完整链路。
常见误区：仅仅在日志中打印 TraceID 是不够的。必须将 TraceID 设置为 Loki 的可索引标签，否则无法实现高效的过滤查询。本课程后续章节将详细讲解标签设计的最佳实践。
1.4 本章小结
可观测性三大支柱——日志、指标、链路——各自解决不同维度的问题，但只有将它们关联起来，才能形成完整的可观测性拼图。日志与链路的关联是打通三大支柱的第一步，也是提升排障效率的关键。在接下来的章节中，我们将深入 Loki 的标签机制与 OpenTelemetry 的链路上下文传播，逐步构建生产级的关联方案。