Aligning diagnostic with Microsoft guidelines

I started to check how to bring the new diagnostics features related to System.Diagnostics. Current iteration looks good but I found a couple of things that might need to be improved.

Diagnostic source scope

MassTransit only works with a single diagnostic source, normally coming from LogContext.Cache.Default. However, the guidelines advise the following:

DO - create new DiagnosticListener for specific Activity type to allow filtering by activity. E.g Incoming and Outgoing Http Requests should be different DiagnosticListeners. Follow DiagnosticSource User Guide to pick a name. (source)

Naming for diagnostic sources and activities

Related to the previous topic, all diagnostic messages are coming from one source that has a name MassTransit, which becomes hard to manage if a user needs, for example, only trace consumer lifecycle.

Another thing is that operation names are not related to the diagnostic source name. Everywhere I look, all operation names are, as a rule, prefixed with the diagnostic source name:

https://github.com/aspnet/AspNetCore/blob/5b2f3fb5f7f24ac3e91c5150a55cc411b2b36b76/src/Hosting/Hosting/src/Internal/HostingApplicationDiagnostics.cs#L18 https://github.com/elastic/apm-agent-dotnet/blob/master/src/Elastic.Apm.AspNetCore/DiagnosticListener/AspNetCoreDiagnosticListener.cs#L31 https://github.com/aspnet/EntityFrameworkCore/blob/f386095005e46ea3aa4d677e4439cdac113dbfb1/src/EFCore.Relational/Internal/RelationalDiagnostics.cs#L12

Does it make sense?

[phatboyg]

The only trick the HTTP handler has is that it needs to be added to the pipeline, so it can force propagation that way. And turn it off by not including the handler in the pipeline. Anyway, I added the ability to turn it off via AppContext or environment variable (yes, basically cut and paste from their code).

[phatboyg]

That makes sense, a lot of sense actually. I put the ability to control in just now via AppContext or environment variable. Not sure what else is left to wrap it up.