Custom Dependency Tracking in Application Insights

[ranjitkrishnan]

I am using ApplicationInsights WCF SDK for monitoring my service. There are some dependency calls in the service like SQL, HTTP calls etc and they are automatically getting tracked. I was trying to track more dependencies to the request like the cache calls using the below code

         client = new TelemetryClient();
         try
        {
            dependencyCall;
        }
        finally
        {
            client.TrackDependency("DependencyName", "CommandName", startTime, stopwatch.Elapsed, true);
        }

I can see the dependency getting tracked in Application Insights. When i made the service request, only the automatic dependencies are linked to the original request. The custom dependencies are not linked to the original request and i showing as a new request.

How can i make the custom dependency to get linked to the main request.? Is it because the TelemetryClient is getting initialized at the class/method level.

Framework installed on server :4.6.2
Target Framework of the service : 4.5.2

[tomasr]

What version of the NuGet package are you using? This seems related to Issue #65....

[ranjitkrishnan]

ApplicationInsights: 2.1.0.0
ApplicationInsights.Wcf : 0.26.0.22375

The issue here is different from #65 . The issue of the original ticket was with the automatic tracking(SQL or HTTP calls) not getting linked to the original request.

Here is the issue is with Custom tracking. I am writing custom code to track details of more dependencies which are not automatically picked up by the SDK. But these dependencies getting logged as a separate request and not with the the original request. I have checked the output JSON in Visual Studio and i can see the parent ids are different in the custom one and the automatic calls

[tomasr]

What do you mean by separate request? Are you saying they are logged on the wrong operation call? Can you share what that looks like in the portal?

[tomasr]

FYI, I just created a simple repro service and I'm seeing dependency events getting associated to the request correctly:

[ranjitkrishnan]

See the screenshots below.

Screenshot 1:

Telemetry entry related to the service call. You can see the SQL call and REST based calls as dependencies there. It doesnt have the Custom trace i did

Screenshot 2:

Telemetry entry related to the custom trace.

You can see that it came as a separate telemetry with just the custom trace dependency.

Now i have tested further by making the custom call after one actual dependency call. In my case, i did the custom trace after my rest based call. Now we can the custom trace is getting linked to the main request as shown below.

Looks like context is not getting set before an actual dependency call. If we make a custom trace dependency before an automatically picked up dependency like SQL or HTTP call, it is not getting linked to the parent request and getting traced as a seperate telemetry item

[tomasr]

Interesting, there's certainly something else going on.... because it also seems like your requests are getting traced twice (once using the WCF handling and once using.... something else. Do you by any chance also have the Microsoft.ApplicationInsights.Web NuGet package installed on your service application?

[ranjitkrishnan]

Yes. I do have Microsoft.ApplicationInsights.Web installed in the service project.

[tomasr]

Well, that explains it.... unfortunately, it's not possible to have both coexist nicely in the same application. There are basically some challenges:

• For HTTP-bindings, the ASP.NET HttModules will kick in and see the request (meaning the ASP.NET AI httpModule will create a Request event for it) and then WCF will see it and... create a second one. It didn't used to be possible to avoid this, but maybe I should look into it again.
• The telemetry modules injected by the ASP.NET package will usually not do the right thing for WCF, since they only see the HTTP request context, and not much else.

Is there a reason you need both the Web and WCF packages installed into the project? If you don't, try removing the Web package and it should do the right thing.

I'll look into this some more and see if there's a better way to get them to coexist...

[ranjitkrishnan]

You are right Tom.

I think Web nuget package might have came in the project as part of the WCF install and i really doesn't need that. I have uninstalled the package and it worked and now i can see the dependencies getting linked properly.

Thanks for the assistance.

[tomasr]

WCF shouldn't be bringing in the Web package. However, a common issue I've run into a couple of times myself is when creating the project letting the "Enable Application Insights" checkbox in the New Project dialog checked, and that will bring it in for sure (I think all the AI-related features in Visual Studio right now would end up bringing it in, including the "connect project to Application Insights" feature).

[ranjitkrishnan]

Correct. May be i would have done that. I dont exactly remember how i enabled application insights in my project now.

[ranjitkrishnan]

I have a question. Is the request time noted in the service call, the time it got picked up by WCF or the time the request got picked up by ASP.NET. If it is WCF, then would not the request time logged by AI, a little less than the actual ? Especially in a load scenario?

[tomasr]

@ranjitkrishnan That is correct, we log the time when the request is picked up by WCF. Usually, ASP.NET time should not be significant and if you do not need ASP.NET integration, you can basically remove it by disabling ASP.NET compatibility in the service hosting environment settings.

But even then, there are things we won't be able to pick up....

For example, I have found no way reliable way to hook earlier in the processing pipeline, and so if WCF is throttling the request (due to the use of <serviceThrottling>), we won't be able to include that time in the AI telemetry.

That's something I am still researching on how to accomplish in a good way (but just might be impossible due to the WCF architecture).