How can we make sure that dependencies are automatically tracked

[fgheysels]

Is your feature request related to a problem? Please describe.

When creating an API that uses Arcus.Observability for logging to Application Insights, dependencies to SQL Server are not automatically tracked.

However, when I would use the default ApplicationInsights integration that is provided by Microsoft, calls to SQL Server are automatically tracked in AppInsights:

In the above screenshot, I've configured Arcus.Observability logging and I've also made sure that I've added MS Application Insights middleware by calling builder.Services.AddApplicationInsightsTelemetry().

As you can see, the dependency to SQL Server is tracked and the request is tracked twice (once by Arcus, once by Microsoft).
However, If I remove the AddApplicationInsightsTelemetry method call, then the dependency to SQL server is no longer logged.

How come this is not logged anymore ? My guess would be that the dependency is logged by the Microsoft.Data.SqlClient package, and not by the MSFT Application Insights middleware itself. However, there must be something that happens inside that middleware that makes it possible.

Describe the solution you'd like
When using Arcus Observability for logging, dependencies to other systems should also be automatically tracked, just like it is done out-of-the-box.

[fgheysels]

I've been looking into the code of the SqlClient library, but cannot find any calls to log requests there, so it must be done via the Application Insights middleware ?

[fgheysels]

The ApplicationInsights sdk contains a DependencyCollector project that contains some interesting types.

If we look at the AddApplicationInsights extension method from Microsoft, we can see there's a call to a method which is called AddCommonTelemetryModules which in turn seems to set up dependency tracking:

The AddAndConfigureDependencyTracking method sets up the DependencyTrackingTelemetryModule which is defined in the DependencyCollector assembly.

I think we should investigate if we can leverage this functionality from our Arcus middleware as well.

[fgheysels]

Just additional information:
To have best of both worlds (automatic dependency tracking & Arcus logging extension methods), I've setup Serilog as a logger with the Arcus ApplicationInsights sink, but I'm not using the Arcus request-tracking middleware; instead, I'm using the Microsoft middleware.

[stijnmoreels]

That's an interesting idea. If we could have something that does this for us. Previously, Microsoft was using activities to do this. And each dependency was starting an activity which was tracked.
It is also worth noting that the dependencies that we allow tracking, are far more extensible and customizable, for ex: passing additional contextual values.

[stijnmoreels]

A quick view showed that there's an observer looking for general diagnostic events, and if the events matches a given SQL name, then it is considered from the SQL client. Maybe we can define our own observer and use our own logging system.
https://github.com/microsoft/ApplicationInsights-dotnet/blob/405fd6a9916956f2233520c8ab66110a1f9dcfbc/WEB/Src/DependencyCollector/DependencyCollector/Implementation/SqlClientDiagnostics/SqlClientDiagnosticSourceListener.cs#L867

[fgheysels]

That's an interesting idea. If we could have something that does this for us. Previously, Microsoft was using activities to do this. And each dependency was starting an activity which was tracked. It is also worth noting that the dependencies that we allow tracking, are far more extensible and customizable, for ex: passing additional contextual values.

That's true, but having this out of the box is really very valuable: you don't have to do it yourself, and you already have a ton of information out of the box.
In Asp.Net core, you can now also choose to disable the automatic dependency tracking, so that's something we could also do if people want to do it theirselves and have more control.

[fgheysels]

A quick view showed that there's an observer looking for general diagnostic events, and if the events matches a given SQL name, then it is considered from the SQL client. Maybe we can define our own observer and use our own logging system. https://github.com/microsoft/ApplicationInsights-dotnet/blob/405fd6a9916956f2233520c8ab66110a1f9dcfbc/WEB/Src/DependencyCollector/DependencyCollector/Implementation/SqlClientDiagnostics/SqlClientDiagnosticSourceListener.cs#L867

We can, but I believe that will be a lot of work, no ?
Also, keep in mind that we should then not only do that for SqlClient, but also for ServiceBus, EventHubs, etc.... My first idea would be to consider if we can somehow re-use the classes that are available in that DependencyCollector project.

[stijnmoreels]

Yeah, that would be nice, the problem is that we handle correlation differently. We use user-defined correlation accessors so that people are able to extend on the correlation and use the correlation outside Microsoft-specific dependencies. The problem is that all Microsoft dependencies are using Activities instead of dependency injection to handle correlation.
We could try to move towards that approach, but it will have to be with the new W3C transition too, plus, we would have to rework our entire correlation Serilog setup, too. Will need a lot of analysis for that.

[fgheysels]

I think this can be closed ?

[stijnmoreels]

It should be okay now, indeed. This also includes Messaging, but that is not yet released, though.

[stijnmoreels]

Ok, now we can close this! 😄