三大支柱：Traces、Metrics、Logs

可观察性建立在三大支柱之上：Traces（链路追踪）、Metrics（指标）、Logs（日志）。

第一个支柱是 Traces（链路追踪）。它记录分布式系统中的请求路径，展示请求经过的服务。

第二个支柱是 Metrics（指标）。它量化系统性能和资源使用，反映系统状态。

第三个支柱是 Logs（日志）。它记录详细的事件信息，描述具体发生的事件。

这三个支柱并非孤立存在，它们通过 Trace ID 关联在一起，形成完整的可观察性体系。本节将深入介绍每个支柱的定义、结构、类型和应用场景。

Traces（链路追踪）

定义和核心概念

Traces，也称为分布式请求路径，定义为：一个用户请求在分布式系统中，从进入系统到完成响应，所经过的所有服务、组件和节点的完整执行路径。

理解 Traces 需要掌握三个核心概念：

Trace：Trace 表示一次完整的请求过程，包含该请求在系统中经过的所有操作。例如，用户请求"查询订单"，整个流程构成一个 Trace。

Span：Trace 由多个 Span 组成。每个 Span 代表一次具体的操作或处理单元。在查询订单的 Trace 中，可能包含"调用 API Gateway"的 Span、"查询用户服务"的 Span、"查询数据库"的 Span。每个 Span 都是 Trace 的一部分。

Trace ID：Trace ID 是一个唯一标识符，在整个请求生命周期中保持不变。无论请求经过多少个服务，Trace ID 都保持一致。Trace ID 用于关联同一请求的所有 Span。

结构示例

以用户请求"查询订单"为例，Trace ID 为 5b8aa5a2d2c872e8321cf37308d69df2，总耗时为 500 毫秒。

该 Trace 包含以下 Span：

API Gateway Span，耗时 50 毫秒（请求入口）
User Service Span，耗时 120 毫秒，包含子 Span：Database Query，耗时 80 毫秒
Product Service Span，耗时 200 毫秒，包含两个子 Span：Cache Lookup（5 毫秒）和 Database Query（180 毫秒）
Payment Service Span，耗时 300 毫秒，包含子 Span：External API Call，耗时 250 毫秒

通过 Trace，开发者可以：

清楚地看到请求经过的服务
了解每个服务的耗时
快速识别性能瓶颈（如 Payment Service 耗时最长）

应用场景

Traces 在分布式系统中有广泛的应用场景：

故障排查与调试：通过 Trace ID 快速找到相关 Span，查看状态码、错误信息、耗时等，识别问题的服务、操作和具体原因。

性能优化：分析每个 Span 的耗时，识别慢操作（如数据库查询、外部 API 调用），优化这些慢操作。

服务依赖分析：理解服务间的调用关系，发现服务依赖模式。这对于系统架构设计和优化非常重要。

用户体验优化：追踪端到端的用户体验，从用户点击到系统响应，优化慢请求，提升用户体验。

实际案例：某电商平台在双 11 期间，订单处理失败率从 0.1% 激增至 5%。使用 Traces，仅需 15 分钟即可定位问题：

通过失败订单找到 Trace ID
查看 Trace 发现 Payment Service 的 Span 显示错误
进一步查看发现 External API Call 超时
定位到第三方支付接口响应慢的问题
快速切换到备用支付通道

这体现了 Traces 的价值：将故障排查时间缩短 60-80%。

Metrics（指标）

定义和核心概念

Metrics（指标）是系统或应用程序在特定时间点的量化测量值，用于描述系统的性能、资源使用和业务状态。

理解 Metrics 需要掌握三个核心概念：

时间序列数据：指标是随时间变化的数据点序列。例如，CPU 使用率每分钟记录一次，形成时间序列，类似股票价格的变化。

指标类型：OpenTelemetry 定义了四种主要的指标类型：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。每种类型有不同的用途。

标签（Labels）：标签用于区分和分组指标。例如，

http_requests_total{path="/api/orders", status="200"}

中，

path

和

status

是标签。开发者可通过标签过滤和分组指标。

指标类型详解

Counter（计数器）：Counter 只能递增，不能递减，用于统计累计值，如请求总数、错误总数。Counter 的值随时间单调递增。例如，

http_requests_total{path="/api/orders"}

= 10000，表示该 API 总共处理了 10000 个请求，该数字会持续增加。

Gauge（仪表盘）：Gauge 可以增加或减少，反映当前状态。例如 CPU 使用率、内存使用量，这些值会上下波动。例如，

cpu_usage_percent

= 75，表示当前 CPU 使用率为 75%，该值可能变化。

Histogram（直方图）：Histogram 用于统计数据分布，如请求延迟的分布情况。它可以显示有多少请求的延迟在 0-100ms、100-200ms、200-300ms 等区间。例如，

http_request_duration_seconds_bucket{le="0.1"}

= 8000，表示有 8000 个请求的延迟小于 0.1 秒。

Summary（摘要）：Summary 用于计算分位数，如 P50、P95、P99 延迟。这些分位数对性能分析非常重要。例如，

http_request_duration_seconds{quantile="0.95"}

= 0.5，表示 95% 的请求延迟小于 0.5 秒。

应用场景

Metrics 的应用场景包括：

性能监控：监控 CPU、内存、网络、磁盘使用率，监控 API 响应时间，监控请求吞吐量。这些指标反映系统的健康状态。

业务指标：监控订单量、用户数、收入等业务指标，监控转化率、完成率等业务流程指标。这些指标反映业务的运行状况。

告警触发：当指标超过预设阈值时，系统自动触发告警。例如，CPU 使用率超过 90%，或错误率超过 1%，都可以触发告警。

容量规划：基于历史 Metrics 数据，预测未来资源需求，优化资源配置，避免资源浪费或资源不足。

通过综合多个指标，开发者可以全面了解系统状态。

Logs（日志）

定义和核心概念

Logs（日志）是系统或应用程序在运行过程中记录的详细事件信息，用于记录系统行为、错误和状态变化。

理解 Logs 需要掌握三个核心概念：

结构化日志：结构化日志使用 JSON 等格式记录，便于解析和查询。例如：

{
  "timestamp": "2026-01-15T10:30:00Z",
  "level": "ERROR",
  "message": "Database connection failed",
  "trace_id": "abc123",
  "user_id": "user-456",
  "service": "order-service"
}

该日志包含时间、级别、消息，以及 trace_id、user_id 等关联字段。

日志级别：日志有不同的级别：DEBUG（调试）、INFO（信息）、WARN（警告）、ERROR（错误）、FATAL（致命）。不同级别用于不同场景。

关联字段：日志中包含 Trace ID、Span ID、用户 ID 等关联字段，用于关联 Traces 和 Metrics。开发者可通过 Trace ID 找到相关的所有数据。

日志类型和应用场景

应用日志：应用日志记录业务逻辑的执行情况，如"用户登录"、"订单创建"、"支付成功"。它也记录错误和异常信息，如"数据库连接失败"、"第三方 API 调用超时"。

系统日志：系统日志记录操作系统的事件，如系统资源使用情况、服务启停记录。这对系统运维非常重要。

访问日志：访问日志记录 HTTP 请求、API 调用、用户访问轨迹。这对分析用户行为和系统访问模式很有用。

Logs 的应用场景包括：

错误诊断：当系统出现错误时，查看错误日志快速定位问题。例如，看到"Database connection failed"的日志，开发者知道数据库连接出现问题。

行为分析：分析日志，了解用户行为和系统行为。例如，分析用户访问日志，了解用户的使用习惯。

审计追踪：记录关键操作和变更，用于审计和合规。例如，记录"用户权限变更"、"系统配置修改"。

调试开发：在开发过程中，通过日志定位问题，了解代码的执行流程。

三者的关系和互补性

Traces、Metrics、Logs 并非孤立存在，它们通过 Trace ID 关联在一起，形成完整的可观察性体系。

Metrics 告诉开发者"是什么"。Metrics 提供系统状态的概览、性能趋势、异常检测。当 Metrics 显示错误率上升时，开发者知道有问题，但不知道问题位置。

Traces 告诉开发者"在哪里"。Traces 展示问题发生的位置、服务调用路径、性能瓶颈点。当 Traces 显示某个服务的 Span 有错误时，开发者知道问题在该服务，但不知道原因。

Logs 告诉开发者"为什么"。Logs 提供错误的详细信息、上下文信息、执行过程记录。当 Logs 显示"Database connection timeout"时，开发者了解问题原因。

典型的排查流程：

Metrics 显示错误率上升（发现问题）
通过 Trace ID 查看相关的 Traces，定位到某个服务（定位位置）
通过 Trace ID 查看相关的 Logs，找到错误原因（了解原因）

这体现了三者的互补性：Metrics 发现异常，Traces 定位问题，Logs 分析原因。三者结合，才能实现完整的可观察性。

本节小结

在本节中，我们学习了可观察性的三大支柱：

第一个是 Traces（链路追踪）。Traces 记录分布式系统中的请求路径，帮助开发者快速定位问题位置，识别性能瓶颈。

第二个是 Metrics（指标）。Metrics 量化系统性能，监控业务指标，触发告警，提供系统状态的概览。

第三个是 Logs（日志）。Logs 记录详细的事件信息，用于错误诊断和行为分析。

三者的关系是：

Metrics 发现异常
Traces 定位问题
Logs 分析原因
三者通过 Trace ID 关联

只有将三者结合使用，才能实现完整的可观察性。

在下一节，我们将深入了解信号关联：为什么需要关联？如何实现关联？Trace ID 是如何工作的？