Search code examples
.net-coreinstrumentation

DiagnosticSource - DiagnosticListener - For frameworks only?


There are a few new classes in .NET Core for tracing and distributed tracing. See the markdown docs in here:

https://github.com/dotnet/corefx/tree/master/src/System.Diagnostics.DiagnosticSource/src

As an application developer, should we be instrumenting events in our code, such as sales or inventory depletion etc. using DiagnosticListener instances and then either subscribe and route messages to some metrics store or allow tools like Application Insights to automatically subscribe and push these events to the AI cloud?

OR

Should we create our own metrics collecting abstraction and inject/flow it down the stack "as per normal" and pretend I never saw DiagnosticListener?

I have a similar need to publish "health events" to Service Fabric which I could also solve (abstract) using DiagnosticListener instances sprinkled around.


Solution

  • DiagnosticListener intends to decouple library/app from the tracing system: i.e. any library can use DiagnosticSource` to notify any consumer about interesting operations.

    Tracing system can dynamically subscribe to such events and get extensive information about the operation.

    If you develop an application and use tracing system that supports DiagnostiListener, e.g. ApplicationInsights, you may use either DiagnosticListener to decouple your code from tracing system or use it's API directly. The latter is more efficient as there is no extra adapter that converts your DS events to AppInsights/other tracing systems events. You can also fine-tune these events more easily.

    The former is better if you actually want this layer of abstraction. You can configure AI to use any DiagnosticListener (by specifying includedDiagnosticSourceActivities) .

    If you write a library and want to rely on something available on the platform so that any app can use it without bringing new extra dependencies - DiagnosticListener is your best choice.

    Also consider that tracing and metrics collection is different, tracing is much heavier and does not assume any aggregation. If you want just custom-metrics/events without in/out-proc correlation, I'd recommend using tracing system APIs directly.