通过 MassTransit 发布者/消费者传播 W3C 跟踪上下文

Question

正在尝试支持从 http 调用 -> 发布者 -> 消费者 -> MassTransit 中的 http 调用传播 W3C 跟踪上下文 traceId 和 spanId 属性（只是现在它们出现在日志/序列中，但我们是使用 Dynatrace），但我在这里找不到任何现成的东西： https://masstransit-project.com/advanced/monitoring/diagnostic-source.html

如果没有可用的东西，我可能会尝试根据这些文章自己创建一些东西：

我可以找到这个作为 OpenTracing 的示例： https://github.com/yesmarket/MassTransit.OpenTracing

这是作为 NServiceBus 的参考： https://jimmybogard.com/building-end-to-end-diagnostics-and-tracing-a-primer-trace-context/

除非有人可以提出一些已经存在的建议？

Answer 1

编辑：还不行，只能在同一个过程中，还需要修复：/

基于 Ryan Bartsch 的库和 Jimmy Bogard 的文章，我创建了这个包，它可以满足我的需要： https://github.com/zidad/MassTransit.ActivityTracing

Answer 2

我是您引用的 MassTransit.OpenTracing 库的作者，但我是在 W3C 推荐之前编写的，它看起来是最近的（2020 年 2 月 6 日）。

我的目标是希望通过一个同时具有同步/HTTP 和异步消息代理通信的微服务架构进行分布式跟踪。对于我使用的 HTTP 内容 OpenTracing.Contrib.NetCore，它“使用 .NET 的 DiagnosticSource 来检测其代码”。对于异步消息代理通信，我将 RabbitMQ 与 MassTransit 一起使用，但我并不真正了解 MassTransit DiagnosticSource 方法suggested on the website（也找不到任何示例），所以我决定深入了解一下具体细节并自己动手。

长话短说，使用 Jaeger 作为追踪器，一切都按预期工作。有趣的是，我们（就像在我工作的公司中一样）决定也使用 DynaTrace，它在低得多的级别上运行，并且在某种程度上消除了在代码中处理大量此类内容的需要。也就是说，该方法并非无效 (IMO)，因为并非每个人都能负担得起 DynaTrace（或类似的 APM 工具）。

我将在接下来的一周或 2 周内尝试使用 W3C 推荐升级这个库。如果你想帮助贡献/审查（或者如果你想朝着不同的方向发展并推出自己的方法），请告诉我也可以）...

Answer 3

Dynatracing 声称与 OpenTracing https://www.dynatrace.com/integrations/opentracing/ 无缝集成，如果您使用您提到的库，并且您的 HTTP 部分使用 OpenTracing 进行检测，那么它可以开箱即用。

唯一的潜在缺点是，在托管服务获取 HTTP 调用并在处理它的上下文中通过 MassTransit 发送或发布消息时，所有内容都必须使用 OpenTracing 进行检测，因为它将使用 OpenTracing API 启动子跨度.

我们使用 Datadog 执行此操作，因此我们使用 Datadog OpenTracing 集成库并使用 OpenTracing Contrib 库跟踪 WebApi 和 HttpClient。所以，自动仪器对我们不起作用。但是使用这些库来检测您的应用程序而不是使用自动检测并不难。

通常的流程是这样的：

• 外部 -> WebApi：开始一个跨度
• WebApi -> MassTransit：启动子跨度，将上下文注入标题
• MassTransit -> 消费者：提取上下文，启动子跨度 等等

注入和提取的两个位都在MassTransit.OpenTracing 库中处理，因此无需额外操作。

对于您的提供者必须支持 OpenTracing 的库，它通常是这样的：

• 配置提供者的跟踪器
• 使用您的提供商提供的集成库将 OpenTracing 全局跟踪器设置为包装器
• 当您使用 OpenTracing 创建跨度时，它将创建一个供应商特定的跨度并将其包装在 OpenTracing 跨度中