No way to correlate dependencies to requests when they are created in background threads

[david-jarman]

I'm working on a production cloud service that uses Application Insights. We have several long running operations that end up making http requests (dependencies) and these are done in background threads to reduce the duration of the APIs we provide.

My current task it to profile the application to see how well we scale. To do this, I need to be able to see how many dependencies each request is making, but I can't seem to find a way to do this for dependencies made in background threads. I thought I would be able to pass along the current operation ID in the CallContext and then use the Operations API to create another telemetry object with the context from the main thread, but StartOperation only allows you to pass in a name.

Is there any way I can unblock myself with AI 2.2.0?

Thanks

[pharring]

You will be able to do this in 2.3. See #163
The Beta3 release has it: https://github.com/Microsoft/ApplicationInsights-dotnet/releases/tag/v2.3.0-beta3

[Dmitry-Matveev]

@david-jarman , could you please confirm if you can achieve the desired outcome with the 2.3-Beta3 as per @pharring suggestion?

[david-jarman]

@Dmitry-Matveev, I have not tried the beta. I am working with a production environment, so using a beta build is not in our best interest.

Is there a workaround that we can use with 2.2.0? For instance, could we use CallContext to set the current operation id of the request and then get it in the background thread and somehow set it in the custom dimensions of the dependency?

[pharring]

@david-jarman Please take a look at the source code for the StartOperation extension method. Apart from the CallContext/AsyncLocal stuff, I think everything it does is in the public surface area, so you could replicate it yourself. It sounds like you already know how to shuttle operation IDs around with CallContext, so that fills in the remaining piece.

FYI, 2.3 stable is planned for 4/7: https://github.com/Microsoft/ApplicationInsights-Home/wiki/SDK-Release-Schedule
Would be great if you can test it now (even if not in production) to confirm it addresses your problem.

[david-jarman]

@pharring, I can give the beta a try to see if it will fix this issue. I will close out this issue if it does. Thanks for the info on the StartOperation extension method too!

[david-jarman]

@pharring and @Dmitry-Matveev, I'm trying the beta and I see the new overload for StartOperation. The problem I'm running into is that when I retrieve the OperationContext from my telemetry client in main thread, the object is null. Therefore, I am unable to pass along the context values into StartOperation in the background thread.

And yes, this is from the context of an ASP.NET request, so there should be a request operation context with operation id, name, and parent id.

Any idea what might be going on?

Edit: I reverted back to 2.2.0 and telemetryClient.Context.Operation was still null.

[david-jarman]

I figured out why the values in the OperationContext object are null. OperationCorrelationTelemetryInitializer.OnInitializeTelemetry is not being called until after the request has already returned a response.

I verified that the correct headers are set in the HTTP requests, it's just that the telemetry initializer is called too late. I will open an issue in the ApplicationInsights-dotnet-server project.

Edit: This is not an issue... The solution is to get the operation id from an extension method from HttpContext, called GetRequestTelemetry.