W3C 跟踪上下文概述

介绍

Dapr 使用 W3C 追踪上下文对服务调用和 pub/sub 消息传递进行分布式跟踪。 在很大程度上，Dapr 负责生成和传播跟踪上下文信息的所有繁重工作，这些信息可以发送到许多不同的诊断工具进行可视化和查询。 作为开发者，您只有在极少数情况下需要传播或生成跟踪标头。

背景

分布式跟踪是一种由跟踪工具实现的方法，用于跟踪、分析和调试跨多个软件组件的事务。 通常情况下，分布式跟踪会游历多个服务，这要求它是唯一可识别的。 跟踪上下文的传播依托于这个唯一标识。

在过去，跟踪上下文传播通常由每个不同的跟踪供应商单独实现。 在多供应商环境中，这会导致互操作性问题，例如：

• 由于没有共享的唯一标识，因此不同跟踪供应商收集的跟踪无法相互关联。
• 跨越不同跟踪供应商之间边界的跟踪无法传播，因为没有统一协商的标识集可以转发。
• 供应商特定的元数据可能会被中介丢弃。
• 因为没有可遵循的标准，云平台供应商，中介和服务提供商无法保证支持跟踪上下文的传播。

在过去，这些问题没有产生重大影响，因为大多数应用程序都由单个跟踪供应商监控，并停留在单个平台提供者的边界内。 如今，越来越多的应用程序被分发到并使用多个中间件服务和云平台。

现代应用的这种转变呼唤建立一种分布式跟踪上下文传播标准。 W3C 跟踪上下文规范 定义了一种普遍认可的交换跟踪上下文传播数据的格式 - 称为跟踪上下文。 跟踪上下文解决了上述问题：

• 为单个跟踪和请求提供唯一标识符，允许将多个供应商的跟踪数据连接起来。
• 提供一个商定的机制，以转发供应商特有的跟踪数据，并在多个跟踪工具参与单个事务时避免出现跟踪中断的情况。
• 提供中介、平台和硬件提供商都可以支持的行业标准。

传播跟踪数据的统一方法提高了分布式应用程序行为的可见性，从而有助于问题分析和性能分析。

场景

您需要了解如何使用跟踪的两种情况：

1. Dapr生成并在服务之间传播跟踪上下文。
2. Dapr 生成跟踪上下文，您需要将跟踪上下文传播到另一个服务，或者你生成跟踪上下文，Dapr 将跟踪上下文传播到服务。

Dapr 在服务之间生成和传播跟踪上下文

在这些场景下，Dapr 会为您完成所有工作。 您不需要创建和传播任何跟踪头。 Dapr 负责创建所有跟踪头并传播它们。 让我们用示例来了解一下这些场景：

1. 单个服务调用 (service A -> service B )

   Dapr 在服务A 中生成跟踪标头，这些跟踪标头从服务A 传播到服务B。

2. 多个顺序的服务调用 （ 服务 A -> 服务 B -> 服务 C）

   Dapr 在服务 A 中请求开始时生成跟踪标头，这些跟踪标头从 服务 A-> 服务 B -> 服务 C 一路传播到进一步启用了 Dapr 的服务。

3. 请求来自外部端点 （例如从网关服务到启用 Dapr 的服务 A）

   Dapr 在服务 A 中生成跟踪标头，这些跟踪标头从服务 A 传播到进一步启用了 Dapr 的服务 服务 A -> 服务 B -> 服务 C。 这与上面的场景 2 类似。

4. Pub/sub消息：Dapr 在发布的消息主题中生成跟踪头，而这些跟踪头被传播到任何监听该主题的服务。

您需要在服务之间传播或生成跟踪上下文

在这些场景下，Dapr 会为您完成一些工作，您需要创建或传播跟踪标头。

1. 从单个服务到不同服务的多次服务调用

   当您从一个服务调用多个服务时，比如像这样从服务A中调用，你需要传播跟踪头。

    service A -> service B
    [ .. some code logic ..]
    service A -> service C
    [ .. some code logic ..]
    service A -> service D
    [ .. some code logic ..] some code logic ..]
    service A -> service C
    [ .. some code logic ..]
    service A -> service D
    [ .. some code logic ..]
   

   在这种情况下，当服务 A 首先调用服务 B 时，Dapr 会在服务 A 中生成跟踪标头，然后这些跟踪标头将传播到服务 B。 这些跟踪标头作为响应标头的一部分在服务 B 的响应中返回。 但是，您需要将返回的跟踪上下文传播到下一个服务，如服务 C 和服务 D，因为 Dapr 不知道您希望重用相同的标头。

   To understand how to extract the trace headers from a response and add the trace headers into a request, see the how to use trace context article.

2. 您已选择生成自己的跟踪上下文标头。 这是很少会遇到的。 您可能会在服务通话中特别选择添加 W3C 跟踪头， 例如，如果您已有的应用程序目前不使用 Dapr。 在这种情况下，Dapr 仍然会为您传播跟踪上下文标头。 如果您决定自己生成跟踪标头，有三种方法可以实现：

   1. 您可以使用行业标准的 OpenCensus/ OpenTelemetry SDKs 生成跟踪头，并将这些跟踪头传递到启用的Dapr 服务。 这是首选的建议。

   2. 您可以使用供应商SDK来生成W3C跟踪标头，如DynaTrace SDK，并将这些跟踪标头传递给启用Dapr的服务。

   3. 您可以遵循 W3C 跟踪上下文规范 来处理跟踪上下文，将这些跟踪标头传递给启用 Dapr 的服务。

W3C 跟踪标头

这些是 Dapr 为 HTTP 和 gRPC 生成和传播的特定跟踪上下文标头。

跟踪上下文 HTTP 标头格式

当将HTTP响应的跟踪上下文头传播到HTTP请求时，您需要复制这些标头。

Traceparent 标头

Traceparent 头以所有供应商都能理解的通用格式在追踪系统中表示收到的请求。 下面是 Traceparent 标头的示例。

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

关于 traceparent 字段的详情可见此处

Tracestate 标头

Tracestate 标头包含特定于供应商格式的父级（parent）。

tracestate: congo=t61rcWkgMzE

Tracestate 字段的详细信息 在这里 。

跟踪上下文 gRPC 标头格式

在 gRPC API 调用中，跟踪上下文通过 grpc-trace-bin 标头传递。

相关链接

• 如何使用 OpenTelemetry 为分布式跟踪设置 Application Insights
• 操作方法: 为分布式跟踪安装 Zipkin
• W3C 跟踪上下文规范
• 可观测性示例