3. 可观测性三支柱：日志、指标、链路追踪，以及它们在混沌工程中的角色

在混沌工程基线核验中，故障注入后的系统行为必须被完整、准确地捕获，才能判断系统是否偏离了预期基线。这依赖于可观测性（Observability）的三大支柱：日志（Logs）、指标（Metrics）和链路追踪（Traces）。三者并非相互替代，而是互补关系，共同构建了故障排查的完整视图。

3.1 三支柱定义与核心差异

理解三支柱的本质区别，是正确选择故障排查工具的前提。下表从数据形态、查询方式和典型用途三个维度进行了对比：

3.2 三支柱在混沌工程中的角色

混沌工程实验的核心是“假设-注入-验证”。三支柱在验证环节扮演着不同但互补的角色：

• 指标（Metrics）：实验的“仪表盘”
  • 负责实时监控系统稳态指标（如 SLO、错误预算、延迟分布）。
  • 当故障注入后，指标率先触发告警，提示系统偏离基线。
  • 典型工具：Prometheus、Grafana。
• 日志（Logs）：实验的“黑匣子”
  • 记录故障注入前后每个服务的详细事件，包括错误堆栈、配置变更、状态切换。
  • 用于事后审计和根因分析，回答“为什么出错”。
  • 典型工具：ELK Stack、Loki。
• 链路追踪（Traces）：实验的“X光机”
  • 追踪单个请求在微服务间的完整调用路径，精确显示每个 Span 的耗时和状态。
  • 在混沌实验中，能直接定位故障影响的具体服务和方法，回答“哪里出错”。
  • 典型工具：Jaeger、Zipkin。

3.3 三支柱协同：从指标告警到链路定位

在混沌工程基线核验中，三支柱的协同工作流程通常遵循“指标发现 → 链路定位 → 日志根因”的闭环：

1. 指标告警触发：Prometheus 检测到 P99 延迟从 200ms 飙升到 5s，触发告警。
2. 链路追踪定位：工程师通过 Jaeger 查询该时间窗口内的 Trace，发现所有请求在调用“payment-service”时出现大量超时 Span。
3. 日志根因分析：进入 payment-service 的日志，搜索对应 TraceID，发现“Redis 连接池获取超时”的详细堆栈。
4. 基线核验：对比基线数据，确认该故障场景下系统行为是否符合预期（如是否触发熔断降级）。

下图展示了三支柱在混沌工程实验中的协同关系：

3.4 链路追踪在混沌工程中的独特优势

虽然三支柱缺一不可，但链路追踪在混沌工程基线核验中具有不可替代的独特价值：

• 端到端可见性：能够跨越多个微服务，完整还原一次故障请求的完整生命周期，这是日志和指标难以做到的。
• 精确的故障边界界定：通过 Span 状态（OK/ERROR）和耗时，可以精确判断故障影响范围（是单个服务还是整个调用链）。
• 依赖关系发现：混沌实验往往暴露隐藏的依赖关系（如非关键路径上的同步调用），链路追踪能自动绘制服务拓扑，帮助发现这些脆弱点。
• 基线对比能力：Jaeger 支持对比不同时间窗口的 Trace 数据，可以直接对比“故障注入前”和“故障注入后”的调用链差异，量化故障影响。

3.5 三支柱数据关联：TraceID 的桥梁作用

在 Jaeger 生态中，TraceID 是实现三支柱数据关联的核心桥梁。通过将 TraceID 注入到日志和指标中，可以实现从“指标告警 → 链路追踪 → 日志详情”的无缝跳转：

// 示例：在日志中注入 TraceID
{
  "timestamp": "2025-03-15T10:30:00.123Z",
  "level": "ERROR",
  "service": "order-service",
  "traceId": "abc123def456",  // 与 Jaeger TraceID 一致
  "message": "Database connection timeout",
  "stackTrace": "java.sql.SQLTimeoutException: ..."
}

这种关联机制使得混沌工程实验的故障排查效率大幅提升：

• 指标 → 链路：Grafana 面板上点击高延迟数据点，直接跳转到 Jaeger 查询对应时间窗口的 Trace。
• 链路 → 日志：在 Jaeger UI 中点击某个 ERROR Span，直接跳转到 Kibana 或 Loki 搜索该 TraceID 对应的日志。
• 日志 → 链路：在日志中看到异常后，复制 TraceID 到 Jaeger 搜索框，查看该请求的完整调用链。

下图展示了 TraceID 如何作为核心关联键，打通三支柱数据：