apm-agent-dotnet: Elastic.Apm.AspNetFullFramework not showing database calls

Only the HTTP calls are shown in Kibana in the Trace sample, there is nothing on database calls There is nothing in the documentation specific to database queries interception for the full .net framework - https://www.elastic.co/guide/en/apm/agent/dotnet/current/setup.html#setup-asp-net

Steps to reproduce the behavior:

Create a new project ASP.NET Web Application (.NET Framework) with MVC and add the Elastic.Apm.AspNetFullFramework nugget (1.2)
Web.config:

<appSettings>
    <add key="ElasticApm:ServerUrls" value="http://IP.ADDR:8200/" />
  </appSettings>
    <modules>
      <add name="ElasticApmModule" type="Elastic.Apm.AspNetFullFramework.ElasticApmModule, Elastic.Apm.AspNetFullFramework" />
    </modules>

Execute any type of query using System.Data.SqlClient, for example
See the output in Kibana - only HTTP call is shown

Expected behavior Trace sample to include SQL calls as well.

kibana

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 28 (15 by maintainers)

Most upvoted comments

Great! Then this is something that we almost already support.

So, there is no official NuGet package, but we have this project in the repo: https://github.com/elastic/apm-agent-dotnet/tree/master/src/Elastic.Apm.SqlClient

That is the auto instrumentation for SqlClient - meaning db calls will be automatically captured for you.

If you clone the repo and build that project you can create an assembly from that.

That will give you a SqlClientDiagnosticSubscriber() class.

After that, all you need to do is to execute this once, preferably during the startup of the application:

Agent.Subscribe(new SqlClientDiagnosticSubscriber());

This way you can give it a try.

But please keep in mind this is not an officially released component yet.

The main reason it’s not yet released is because we don’t have a solution for scenarios when EF or EF Core is used with MSSql - in that case EF (Core) uses SqlClient internally, so db calls would be captured twice. Which in your case is not relevant, so that’s good.

Once we have a solution for this problem, the plan is to have an official release of this package.

gregkalapos on Jan 21, 2020

@vhatsura appreciate all your help here! Even if it’s mostly brainstorming and ideas, the Elastic team could still benefit from all the research we’ve done so far.

I totally agree with you. My mention was related to not retranslate my words on behalf of the owners.

NET45 referencing .net core System.Net.Http supports diagnostic listener

So, this mention is related to the case, when you reference .net core System.Net.Http as a NuGet package in .Net Framework application. To be honest, DiagnosticsSource is available for .Net Framework as a NuGet package. However, .Net Framework version of SqlClient, don’t spread trace events through DiagnosticsSource.

vhatsura on Jan 22, 2020

@sawo1337, first of all, to be clear. I’m not working for Elastic, I’m just an external contributor.

What I see from ApplicationInsights code. For the .Net 4.5 there is the usage of EventListener. However, there is also SqlClientDiagnosticSourceListener which enabled by default for .Net Core and .Net Framework targets. So, I’ll look into this area if the Elastic team isn’t minding.

vhatsura on Jan 22, 2020

Small update:

SqlClient for .Net Framework doesn’t spread events via DiagnosticSource. I checked all .Net Framework versions from 461 to 472. So, it can be a little chance for .Net Framework 4.8, however, I think most of the users want tracking db calls also for 461 or 472.

SqlClient for .Net Framework fire events via EventListener under Microsoft-AdoNet-SystemData name. I’ve been started to implement such functionality in Elastic.Apm.

vhatsura on Jan 22, 2020

So, I’ll look into this area if the Elastic team isn’t minding.

If course, happy to take any input!

EventListener is also something we can look into - so, DiagnosticSource isn’t the only thing we are ok with - whatever gives us the traces with acceptable overhead is ok.

gregkalapos on Jan 22, 2020

@sawo1337, I’m afraid of Elastic.Apm.SqlClient package cannot be helpful in the case of .Net Framework. Unfortunately, SQLClient for .Net Framework doesn’t use DiagnosticSource, which allows to Elastic.Apm capture information about calls in user code. So, at the moment, Elastic.Apm.SqlClient package can be used only for SQLClient in .Net Core applications. So, the only possible way to capture db calls in .Net Framework is to use Public Agent API, which was mentioned by @gregkalapos.

Alternatively, you can also manually track the db calls by the public agent API - although I admit this is less convenient.

@gregkalapos, FYI, I created an issue #702 to add documentation for Elastic.Apm.SqlClient,

vhatsura on Jan 21, 2020

@sawo1337 In case you work with Visual Studio - when Elastic APM .NET Agent switched to .NET Core SDK 3.1.* it stopped building in my environment with Visual Studio 2017 with errors similar to the ones you posted above. I installed Visual Studio 2019 and it started to build again.

SergeyKleyman on Jan 21, 2020