OpenTelemetry instrumentation for MediatR

[julealgon]

Every major framework is now being instrumented with OpenTelemetry (aspnet itself, http, ef, etc). I think it would make sense for MediatR to have its own instrumentation library (or built-in instrumentation) to work with OpenTelemetry standards.

Thoughts? Has this been considered before?

From a developer perspective, it would be nice to have custom spans for MediatR operations show up in traces, as well as any metrics that would be particular to the library.

[SilentBlueD666]

I was just working on this yesterday; I simply created a pipeline behaviour. Or are you saying out of the box would be better? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Juliano Leal Goncalves ***@***.***> Sent: Tuesday, July 12, 2022 11:31:25 PM To: jbogard/MediatR ***@***.***> Cc: Subscribed ***@***.***> Subject: [jbogard/MediatR] OpenTelemetry instrumentation for MediatR (Discussion #762) Every major framework is now being instrumented with OpenTelemetry (aspnet itself, http, ef, etc). I think it would make sense for MediatR to have its own instrumentation library (or built-in instrumentation) to work with OpenTelemetry standards. Thoughts? Has this been considered before? From a developer perspective, it would be nice to have custom spans for MediatR operations show up in traces, as well as any metrics that would be particular to the library. — Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjbogard%2FMediatR%2Fdiscussions%2F762&data=05%7C01%7C%7C0b1c4b7d90e64288d89b08da64564218%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932618884205313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DAvXT1oyxh%2FNJZZGALT3pxcLTiGtpj1STeWrS66IZ9o%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADE3ZABP3GM6QRIGLPWWDQLVTXW33ANCNFSM53MRZE2A&data=05%7C01%7C%7C0b1c4b7d90e64288d89b08da64564218%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932618884205313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m0TUfY0zciqDd9zRtYxH1TVBnQ6f8%2BMbE%2BUwalPrDCk%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[julealgon]

I was just working on this yesterday; I simply created a pipeline behaviour.

I'm not sure what you mean. Are you saying you instrumented it on your own inside your application?

Or are you saying out of the box would be better?

This question is also not clear to me. There are basically 2 ways the instrumentation could be provided "out of the box":

1. The main MediatR package itself has it built-in
2. There is a separate OpenTelemetry.Contrib.Instrumentation.MediatR type of package that adds the instrumentation

Out of the 2 above, I actually don't have a strong opinion on which is the preferred approach (I don't know if 1 is a good practice or not).

Hope this clarifies it.

[jbogard]

I dunno, I'm not sure if it would add more noise to your traces. The frameworks you listed are all dealing with I/O, so I'd already have traces around incoming HTTP requests, any data access, any messages consumed/produced, and any outgoing HTTP requests. I don't know what another trace would add.

[julealgon]

That's fair. I'm also not 100% sure myself if this would be a good idea or not but I figured I'd ask since I'm working quite heavily on OTel stuff lately.

What I can say from a consumer perspective, is that I've already created tracing decorators for MediatR in the past to integrate with XRay (AWS's custom tracing solution) and that actually helped me getting a better domain view of my operations.

Sometimes, having just the HTTP request information is a bit too "raw", if you know what I mean. MediatR is usually used to model something closer to the domain that has more semantic value involved and such. The additional span in the trace exposing this more semantic information was fairly useful in my scenario.

Also, I want to add that it would be quite nice to have MediatR tracing for worker-type processes (i.e. services that run on a pure console, or a windows service, etc). Those are not necessarily activated by an external event (like an HTTP request or a queue push), so without custom tracing, they would not output anything even with all the existing instrumentation packages added. MediatR could be the tracing starter in these scenarios.

[jbogard]

That's fair, but it's pretty easy to add via behaviors now that the Activity/Diagnostics API has been improved.