ApplicationInsights-dotnet: Undistinguishable calls problem

We will need to solve the problem of undistinguishable calls. In a nutshell the problem is that many POST requests and POST dependencies has the same name, same url and ultimately only differs by timestamp. In this case the ROI of Application Insights telemetry is not very high.

Undistinguishable POST requests may not be that bad as traces, exceptions and such will be collect for them. Undistinguishable POST dependencies are pretty much a brick wall for root cause analysis.

Collection of post body automatically is a big privacy concern. There is a workaround by @Dmitry-Matveev to collect extra information (like for this case):

Implement custom Telemetry Initializer (AI extension point for data enrichment).
If they can access those parameters from synchronous code within their request (Telemetry Initializers are executed in the customer call stack synchronously), then customer can implement it right away:
Telemetry Initializer looks if Request has failed and if the code is 500;
Then Telemetry Initializer adds the necessary parameters to the custom dimensions;
In this case customer fully controls the collection and the times when this information is exposed;

However we do not have an easy one for dependencies as telemetry initializers cannot access http request object when enriching DependencyTelemetry object.

So the minimal set of action items here we should:

Document Dmitry’s list
Make it easy to extend automatically-collected dependencies with extra request information
Think of an easy wins in this area which will allow to improve automatic story. Like support WCF calls natively and get exception details from the response payload or including the non-standard Http Response status message for the failed dependencies.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 4
Comments: 17 (8 by maintainers)

Most upvoted comments

@sc22github

this is not specific to application insights. this is the problem of WebHttpRequests: execution context does not flow between begin/end requests. Even if you use HttpClient, AppInsights interacts with HttpWebRequests underneath.

There is no such problem on .NET Core.

You may be able to achieve what you want using raw request and response objects on dependency telemetry to enrich it using ITelemetryInitializer (not processor) with something like

    public class DependencyContentTelemetryInitializer : ITelemetryInitializer
    {
        public void Initialize(ITelemetry telemetry)
        {
            if (telemetry is DependencyTelemetry dependencyTelemetry)
            {
                if (dependencyTelemetry.TryGetOperationDetail("HttpRequest", out var request) 
                    && request is HttpWebRequest httpRequest)
                {
                    ...
                }
            }
        }
    }

lmolkova on Aug 15, 2019

I hit this issue when using EWS calls via SoapHttpClientProtocol. While I was using 2.2 I managed to work around by using CallContext to store the method name during the GetWebResponse override, and having a telemetry initializer pick it up. But once I upgraded to 2.4 the initializer no longer runs synchronously during GetWebResponse, so the workaround doesn’t work anymore.

Correction: I had a telemetry processor, not an initializer. The initializers do seem to run synchronously, but now they run before GetWebResponse, so my attempts at creating activities in GetWebResponse didn’t work. I was able to do something by creating the activity where the “Begin<webservicemethod>” is called; with this, and moving the code to an initializer I was able to pick up the name of the EWS method. The only unfortunate problem is that SoapHttpClientProtocol does not seem to have a virtual method where I can do that for all web methods, so I need to do it on the call site.

fpintos on Jul 6, 2017