追踪与跨度：你应该知道的可观测性基础知识 | Last9

来源: https://last9.io/blog/traces-spans-observability-basics/ 抓取时间: 2026-07-21 16:24:27

在现代软件架构中，应用程序不仅仅是变得更大——它们变得更加分布式。随着微服务、无服务器函数和容器在多个环境中运行，理解系统内部发生的事情可能感觉像是试图在风暴中追踪一滴雨水。

这就是追踪和跨度的用武之地。这些可观测性工具不仅仅是流行词——它们是让你理解复杂分布式系统的秘密武器。让我们分解什么是追踪和跨度，它们为什么重要，以及如何使用它们来更快地进行故障排除并构建更可靠的系统。

理解追踪和跨度：核心概念

追踪捕获请求在分布式系统中移动的旅程。将追踪视为从开始到结束的完整请求故事——从用户点击按钮直到他们看到结果。

跨度是追踪的构建块。每个跨度代表该旅程中的一个工作单元——比如数据库查询、API 调用或函数执行。跨度相互嵌套，以显示操作之间的父子关系。

以下是简单关系：

• 一个追踪包含多个跨度
• 每个跨度代表一个操作
• 跨度具有时序数据和元数据
• 跨度可以嵌套以显示操作如何相互关联

追踪
├── 跨度（API 网关）
│   ├── 跨度（认证服务）
│   └── 跨度（用户服务）
│       └── 跨度（数据库查询）
└── 跨度（响应格式化）

💡 如果你好奇追踪和跨度如何与指标、日志和事件配合，这篇文章分解了所有四个支柱。

追踪和跨度对 DevOps 专业人员的好处

你正在运行一个包含数十个微服务的复杂系统。突然，用户报告结账过程很慢。没有追踪，你需要单独检查每个服务，浪费宝贵的时间。

通过追踪和跨度，你可以：

1. 立即找到瓶颈：准确查看哪个服务或函数耗时过长
2. 跨服务边界调试：跟随请求在服务之间跳转
3. 理解依赖关系：可视化你的服务如何连接和相互依赖
4. 提高性能：精确地识别和修复慢速操作
5. 减少平均恢复时间（MTTR）：在出现问题时更快找到根本原因

追踪和跨度的技术实现

让我们深入了解追踪在分布式系统中工作的具体细节。

追踪上下文和传播

为了使追踪跨服务边界工作，每个服务需要知道它正在处理同一请求的一部分。这通过上下文传播实现——在服务之间传递追踪 ID 和跨度 ID。

当请求首次到达你的系统时，它会被分配一个唯一的追踪 ID。随着请求在服务之间移动，这个 ID 随其一起传递（通常作为 HTTP 头）。然后每个服务创建自己的跨度，但将它们链接到同一个追踪。

跨度属性和事件

跨度不仅仅是时间戳——它们富含数据：

• 名称：这个跨度代表什么操作
• 时序：开始和结束时间
• 状态：成功、错误等
• 属性：自定义键值对（如 user_id 或 cart_size）
• 事件：跨度内的显著发生
• 链接：到其他跨度的连接

采样策略

追踪所有内容可能会产生大量数据。这就是为什么大多数系统使用采样——只收集一定百分比的追踪。智能采样策略包括：

• 基于头部的采样：在请求开始时决定是否采样
• 基于尾部的采样：请求完成后决定（更适合捕获错误）
• 优先级采样：始终追踪重要操作，但对常规操作进行采样

💡 如果你想理解可观测性、遥测和监控之间的区别，请查看这篇有用的文章：可观测性 vs 遥测 vs 监控。

追踪实现指南：工具和框架

准备好向你的系统添加追踪了吗？以下是你需要的：

OpenTelemetry：行业标准

OpenTelemetry 已成为实现追踪和跨度的首选框架。它提供：

• 所有主要编程语言的库
• 供应商中立的 API 和 SDK
• 流行框架的自动插桩
• 收集和导出数据的一致方式

追踪工具箱

有几个工具可以帮助你收集、存储和可视化你的追踪：

如果你正在寻找适合预算的可观测性解决方案，Last9 值得一试。通过基于摄取事件的定价，它保持了可预测性。此外，我们的平台大规模处理高基数数据，并与 OpenTelemetry 和 Prometheus 集成，将你的指标、日志和追踪集中在一个地方。

在你的代码中实现追踪

以下是使用 OpenTelemetry 在 Node.js 应用程序中创建跨度的简化示例：

// 初始化 OpenTelemetry SDK（在你的应用中执行一次）
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");
const { SimpleSpanProcessor } = require("@opentelemetry/sdk-trace-base");
const {
  OTLPTraceExporter,
} = require("@opentelemetry/exporter-trace-otlp-http");


const provider = new NodeTracerProvider();
const exporter = new OTLPTraceExporter({
  url: "http://localhost:4318/v1/traces",
});
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));
provider.register();


// 获取追踪器
const { trace } = require("@opentelemetry/api");
const tracer = trace.getTracer("my-service");


// 在你的代码中创建跨度
async function processOrder(orderId) {
  const span = tracer.startSpan("process-order");


  // 向跨度添加属性
  span.setAttribute("order.id", orderId);
  span.setAttribute("customer.type", "premium");


  try {
    // 执行工作...

    // 创建子跨度
    const dbSpan = tracer.startSpan("database-query", {
      parent: span,
    });


    try {
      // 运行数据库查询...
      dbSpan.end();
    } catch (error) {
      dbSpan.setStatus({ code: SpanStatusCode.ERROR });
      dbSpan.recordException(error);
      dbSpan.end();
      throw error;
    }


    span.end();
  } catch (error) {
    span.setStatus({ code: SpanStatusCode.ERROR });
    span.recordException(error);
    span.end();
    throw error;
  }
}

💡 想知道 OpenTelemetry 与传统 APM 工具相比如何？这篇文章分解了关键区别：OpenTelemetry vs 传统 APM 工具。

高级追踪技术

一旦你实现了基本追踪，这些高级技术可以将你的可观测性提升到下一个级别。

分布式上下文管理

在复杂系统中，你需要管理不仅仅是追踪 ID 的上下文。W3C 追踪上下文规范为以下内容提供了标准：

• traceparent：包含追踪 ID 和父跨度 ID
• tracestate：允许供应商添加自定义上下文数据

使用这些头确保你的追踪跨不同服务和供应商工作。

追踪、指标和日志之间的关联

可观测性的真正力量来自连接不同的信号：

• 示例追踪：将指标链接到生成它们的追踪
• 日志中的追踪 ID：向日志消息添加追踪 ID 以便交叉引用
• 自定义属性：在所有遥测类型中使用一致的属性

错误处理和异常追踪

当异常发生时，跨度可以提供关键上下文：

• 用错误状态标记跨度
• 记录带堆栈跟踪的异常
• 向跨度添加事件，显示错误的进展
• 创建在跨服务边界携带错误上下文的 baggage 项

💡 要深入了解如何保持领先于问题并提高系统可靠性，请查看这篇关于主动监控的文章：主动监控。

现实世界追踪模式和反模式

有效追踪模式

有意义的跨度名称：使用一致的命名约定，如 service_name/operation 正确的粒度：为重要操作创建跨度，而不是每个函数调用 正确的上下文传播：确保追踪上下文流经所有通信渠道 有用的属性：添加有助于故障排除的属性，如用户 ID 或功能标志 性能意识：注意过度创建跨度的开销

需要避免的追踪反模式

过度插桩：创建太多跨度会导致性能问题 缺失上下文：未能传播上下文会破坏跨服务边界的追踪 不一致的命名：使用不同的命名标准使追踪更难解释 太多数据：在跨度中放置大的有效载荷会使你的追踪后端不堪重负 忽略第三方服务：缺少外部调用的跨度会造成盲点

💡 探索可观测性在 LLM 的性能和可靠性中如何发挥关键作用：LLM 可观测性。

追踪和跨度的业务价值：超越技术好处

追踪不仅仅用于故障排除——它们还可以提供业务见解：

• 端到端跟踪关键用户旅程
• 衡量关键业务操作的性能
• 基于追踪数据设置 SLO（服务水平目标）
• 以真实用户术语量化性能问题的成本
• 通过向跨度添加相关属性来创建业务上下文

当你能够展示技术改进如何影响用户体验和业务指标时，你就弥合了 DevOps 和业务利益相关者之间的差距。

结论

追踪和跨度让你拥有对分布式系统的 X 射线视觉。它们揭示了服务之间隐藏的连接，精确定位性能瓶颈，并显著加速调试。

随着系统变得越来越复杂，这种可观测性不是奢侈品——而是必需品。

💡 如果你想继续关于分布式追踪和可观测性的对话，请加入我们的 Discord 社区，DevOps 专业人员在那里分享他们的经验和最佳实践！

常见问题

追踪和日志之间有什么区别？

日志捕获离散事件，而追踪显示跨服务操作之间的关系。日志告诉你发生了什么；追踪向你展示它是如何发生的。

添加追踪会减慢我的应用程序吗？

现代追踪库增加的开销很小——正确配置时通常不到 3% 的性能影响。通过采样，你可以进一步减少这种影响。

我需要修改所有代码来添加追踪吗？

不一定。许多框架提供自动插桩，可以用最少的代码更改添加追踪。OpenTelemetry 为大多数语言中的流行框架提供自动插桩。

分布式追踪生成多少数据？

根据流量、采样率和跨度细节，差异很大。对于繁忙的系统，计划每天从几 GB 到几 TB 不等。这就是为什么选择正确的可观测性平台对成本控制很重要。

追踪可以帮助安全和合规吗？

是的！追踪创建了请求流经你系统的审计轨迹。通过正确的属性，你可以跟踪哪些用户或服务在何时访问了哪些数据。

追踪和跨度如何与其他可观测性信号配合？

追踪补充了指标和日志。指标在高级别显示系统健康，日志提供详细事件，追踪连接点以显示跨服务的请求流。