So, the automatic instrumentation didn't work for us. We do this with Datadog, so we use the Datadog OpenTracing integration library and trace the WebApi and HttpClient using OpenTracing Contrib libraries. The only potential drawback that in the service that hosts gets an HTTP call and within the context of handling it sends or publishes a message via MassTransit, everything must be instrumented with OpenTracing, because it will start the child span using the OpenTracing API. Let me know if you want to help with contribution/review (or if you want to go off in a different direction and roll your own is also fine).ĭynatracing claims to integrate seamlessly with OpenTracing and if you use the library you mentioned and if you have your HTTP part instrumented with OpenTracing, it will work out of the box.
#MASSTRANSIT CONFIGURE STACKTRACE UPGRADE#
I'll try to upgrade this library with the W3C recommendation in the coming week or 2. That said, the approach is not invalid (IMO), as not everyone can afford DynaTrace (or similar APM tools). Interestingly, we (as in the company I work for) decided to also use DynaTrace, which operates at a much lower level and kind of removes the need for handling a lot of this stuff in code. Long story short, it all worked as expected using Jaeger as the tracer. For the asynchronous message broker communications, I was using RabbitMQ with MassTransit, but I didn't really understand the MassTransit DiagnosticSource approach suggested on the website (and nor could I find any examples), so I decided to get into the nuts and bolts a bit and roll my own. NET's DiagnosticSource to instrument its code'. For the HTTP stuff I was using, which 'uses. My goal was that I wanted distributed tracing through a microservice architecture that had both synchronous/HTTP as well as asynchronous message broker communications.
I'm the author of the MassTransit.OpenTracing library you referenced, but I wrote it prior to the W3C recommendation, which looks to be quite recent (Feb 6, 2020).
0 kommentar(er)
