Dapr 通过 Open Telemetry (OTEL) 和 Zipkin 协议来实现分布式追踪。OTEL 是行业标准,并且是推荐使用的追踪协议。
大多数可观测性工具支持 OTEL,包括:
下图展示了 Dapr(使用 OTEL 和 Zipkin 协议)如何与多个可观测性工具集成。
追踪用于服务调用和发布/订阅(pubsub)API。您可以在使用这些 API 的服务之间传递追踪上下文。追踪的使用有两种场景:
Dapr 负责创建追踪头。然而,当有两个以上的服务时,您需要负责在它们之间传递追踪头。让我们通过示例来了解这些场景:
例如,服务 A -> 服务 B
。
Dapr 在 服务 A
中生成追踪头,然后从 服务 A
传递到 服务 B
。不需要进一步的传递。
例如,服务 A -> 服务 B -> 传递追踪头到 -> 服务 C
,以及其他启用 Dapr 的服务。
Dapr 在请求开始时在 服务 A
中生成追踪头,然后传递到 服务 B
。您现在需要负责获取头并将其传递到 服务 C
,因为这与您的应用程序特定相关。
换句话说,如果应用程序调用 Dapr 并希望使用现有的追踪头(span)进行追踪,它必须始终传递到 Dapr(在此示例中,从 服务 B
到 服务 C
)。Dapr 始终将追踪 span 传递到应用程序。
例如,从网关服务到启用 Dapr 的服务 A
。
外部网关入口调用 Dapr,Dapr 生成追踪头并调用 服务 A
。服务 A
然后调用 服务 B
和其他启用 Dapr 的服务。
您必须从 服务 A
传递头到 服务 B
。例如:入口 -> 服务 A -> 传递追踪头 -> 服务 B
。这类似于案例 2。
Dapr 在发布的消息主题中生成追踪头。对于 rawPayload
消息,可以指定 traceparent
头以传递追踪信息。这些追踪头会传递到任何监听该主题的服务。
在以下场景中,Dapr 为您完成了一些工作,您需要创建或传递追踪头。
当您从单个服务调用多个服务时,您需要传递追踪头。例如:
服务 A -> 服务 B
[ .. 一些代码逻辑 ..]
服务 A -> 服务 C
[ .. 一些代码逻辑 ..]
服务 A -> 服务 D
[ .. 一些代码逻辑 ..]
在这种情况下:
服务 A
首次调用 服务 B
时,Dapr 在 服务 A
中生成追踪头。服务 A
中的追踪头被传递到 服务 B
。服务 B
的响应中返回。服务 C
和 服务 D
,因为 Dapr 不知道您想要重用相同的头。生成您自己的追踪上下文头较为少见,并且在调用 Dapr 时通常不需要。
然而,在某些场景中,您可能会特别选择在服务调用中添加 W3C 追踪头。例如,您有一个不使用 Dapr 的现有应用程序。在这种情况下,Dapr 仍然为您传递追踪上下文头。
如果您决定自己生成追踪头,可以通过三种方式完成:
标准 OpenTelemetry SDK
您可以使用行业标准的 OpenTelemetry SDKs 生成追踪头,并将这些追踪头传递到启用 Dapr 的服务。这是首选方法。
供应商 SDK
您可以使用提供生成 W3C 追踪头的方法的供应商 SDK,并将其传递到启用 Dapr 的服务。
W3C 追踪上下文
您可以根据 W3C 追踪上下文规范 手工制作追踪上下文,并将其传递到启用 Dapr 的服务。
阅读 追踪上下文概述 以获取有关 W3C 追踪上下文和头的更多背景和示例。