跳到主要内容

分布式追踪的上下文传播

如概述中所讨论的，分布式追踪跟踪事件从发布应用、事件代理之间，到接收应用的全过程。分布式追踪，或简称为 追踪，是记录事件消息在事件网格中传播路径的记录。追踪由沿途各点发出的 跨度（spans） 组成。OpenTelemetry 后端，如 Jaeger 或 DataDog，将这些跨度组装成追踪，并提供事件消息整个生命周期的可视化视图。

追踪 上下文 是允许新跨度作为同一追踪中另一个跨度的子跨度创建，或链接到追踪中其他跨度的元数据，无论其他跨度在何处生成。上下文 传播 是事件消息跨服务和进程边界传递该元数据的机制。

让我们通过一个例子来了解上下文传播的工作原理。下图显示了一个简单的架构，包括一个事件代理和两个客户端（一个发布消息，一个消费消息）。每个处理事件消息的过程都会发出一个跨度。这些跨度被接收器消费，然后由 OpenTelemetry 后端系统组装在一起形成追踪。

img

让我们检查这个简化例子中的每个步骤：

  1. 服务 A 使用遥测仪器生成可以添加到消息中的上下文信息。
  2. 服务 A 使用 PubSub+ 消息 API 准备事件消息，并使用 PubSub+ OpenTelemetry API 库将追踪上下文注入到该消息中。服务 A 也可能使用 OpenTelemetry API 分别生成具有相同上下文的 OpenTelemetry 跨度。
  3. PubSub+ 消息 API 将消息发送到事件代理。
  4. 事件代理 接收消息。如果代理有匹配消息主题的追踪过滤器订阅，它会生成一个或多个跨度。将跨度添加到一个或多个追踪消息中，事件代理 将追踪消息发送到遥测队列。
  5. 如果追踪消息成功入队，事件代理 会用跨度的上下文更新事件消息的追踪上下文。这启动了一个发送跨度，即随消息发送到下一个跳转点（可能是另一个事件代理或消费应用）的追踪上下文。在这个例子中，下一个跳转点是消费应用，服务 B。
  6. 服务 B 通过 PubSub+ 消息 API 消费事件消息，并使用 PubSub+ OpenTelemetry API 库提取追踪上下文。然后使用这个追踪上下文建立接收时创建的第一个跨度的父跨度。
  7. 对于发送跨度，事件代理 记录它向 服务 B 发送消息的时间作为发送跨度的开始时间。当 服务 B 消费消息时，会向 事件代理 发送确认。事件代理 接收确认，结束发送跨度，并记录向 服务 B 传递尝试的结果。
  8. 任何时候，Solace Open Telemetry 接收器 都可以连接到 事件代理 接收 Solace 追踪消息并将它们转换为标准的 OpenTelemetry 跨度。其他接收器模块接收生产者和消费者应用创建的遥测跨度。OpenTelemetry 收集器 处理所有跨度，然后可以由后端监控工具关联。

在事件网格的每个跳转点，事件消息都会用最新的上下文信息更新。这扩展了整个追踪，随着事件消息在网格中的移动。

发送跨度的传递不是保证的。

事件代理中的上下文传播​

事件消息中可以传播两种类型的上下文：

  • 跨度上下文 - Solace API 和事件代理可以解释和修改消息传输中的追踪上下文。
  • 行李（也称为相关上下文） - 行李是一组可以注入和从上下文中读取的键值对。Solace API 和事件代理从不修改行李；它们只读取它，并将其包含在追踪消息中。

追踪上下文和行李被携带在事件消息中。如果事件消息成功追踪（即，生成并入队一个跨度），事件代理会用跨度的上下文更新事件消息的追踪上下文。如果在接收事件消息后但在生成跨度之前，事件代理遇到无法追踪事件消息的情况（例如，遥测队列已满），代理会将追踪上下文不变地传递到事件网格中的下一个跳转点。

为了适当处理事件消息并生成跨度，事件代理在接收事件消息时执行以下操作：

  1. 执行基本检查（例如，验证消息的接收流是否有效，消息是否是该流上的下一个预期消息，消息是否符合任何主题访问控制）。如果这些测试失败，消息将被丢弃而不进行追踪。
  2. 确定是否要追踪事件消息。如果消息要被追踪，它在消息的追踪上下文中设置 sampled 标志。否则，它保持 sampled 标志不变。
  3. 处理事件消息。
  4. 使用事件消息的追踪上下文创建子跨度。
  5. 在事件消息和追踪消息被持久化的同时更新事件消息的追踪上下文。事件消息的追踪上下文不会更早更新，以便如果事件代理遇到无法追踪事件消息的情况（例如，遥测队列已满），它不会生成追踪消息 - 它将接收到的追踪上下文不变地传递到事件网格中的下一个跳转点。

事件代理支持通过 HTTP 传播分布式追踪上下文。使用 HTTP 从事件代理发布或消费消息的应用程序可以根据 W3C 标准传播上下文信息。有关更多信息，请参阅 https://www.w3.org/TR/trace-context/。

使用PubSub+消息API进行上下文传播​

PubSub+ 消息 API 的上下文传播由 Solace PubSub+ OpenTelemetry API 库支持。这些库允许您将上下文注入到 PubSub+ 事件消息中或从中提取上下文。

您将 PubSub+ OpenTelemetry API 库与您用于开发应用程序的编程语言的 PubSub+ 消息 API 一起部署。这些库依赖于 OpenTelemetry API（也必须与您的应用程序一起部署）。

Solace PubSub+ OpenTelemetry API 库仅支持 W3C 传播器。

有关特定库的信息，包括如何获取它们，请参见以下链接：

  • 有关 Solace Java API 的 PubSub+ OpenTelemetry 集成，请参阅 Java API 中分布式追踪的上下文传播。
  • 有关 Solace JMS API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 JMS。
  • 有关 Solace JCSMP API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 JCSMP。
  • 有关 Solace .NET API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 .NET。
  • 有关 Solace JavaScript 和 Node.js API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 JavaScript 和 Node.js。
  • 有关 Solace Go API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 Go。
  • 有关 Solace Python API 的 PubSub+ OpenTelemetry 集成，请参阅为分布式追踪配置 Python。

在后端可视化追踪信息​

追踪帮助您了解事件消息在分布式系统中的传播路径。追踪由一个或多个跨度组成，第一个跨度代表根跨度。每个根跨度代表从开始到结束的请求。当一个请求通过分布式系统时，通常会生成多个跨度。如果由请求生成了新的跨度，则被认为是子跨度，生成它的跨度是其父跨度。子跨度提供了在请求过程中发生的步骤的额外上下文。

OpenTelemetry 接收器收集不同类型的跨度，包括来自 OpenTelemetry API 和 PubSub+ 事件代理的跨度。OpenTelemetry 收集器收集、处理并导出这些跨度到后端，在那里它们被组装成端到端追踪的瀑布可视化图。这些可视化图显示了根跨度和其子跨度之间的关系，可以帮助您改进和调试分布式应用程序。下图显示了在分布式系统中不同点生成的跨度如何被组装成 OpenTelemetry 后端的端到端追踪：

有关如何将跨度收集到追踪的详细解释，请参见 OpenTelemetry 追踪。