Application Insights is a great Azure based service for developers, similar to New Relic, that allows you to monitor an application, analyze its performance and get a deeper look into errors that occur in production. All of that without having to care about the infrastructure and management of the monitoring tools. Here, I'll describe how to deal with correlating all telemetry data gathered within one request to an OWIN based application.


When you're diagnosing a problem on production, you want to get as much information as possible about what was actually going on, when the issue occurred. Correlation of all telemetry data, that was gathered within a single operation that resulted in the error, may be very helpful.

Application Insights provide you with the concept of the OperationId. It's an identifier, that you assign to all telemetry reported for a certain operation. When analyzing the telemetry data, you can then search by this identifier, to get all telemetry related to the operation. This way you can easily check what SQL or HTTP dependencies were called during a certain requests, as well as check what were the traces sent by the application.

All available telemetry for this operation

Issues with AI and OWIN

When you turn on Application Insights for an application, by default you will get tracking for all requests. The correlation is built-in, however there are two problems you will face:

  1. If you do any async operation during processing the request, the correlation id will be lost.
  2. If you are self-hosting your app, the correlation (and even the request tracking) will not work. The default mechanism relies on HttpModule plugged into the System.Web pipeline, which is not available in self-hosted scenario.

In Application Insights SDK 2.0, a new TelemetryClient extension method was introduced, that enables you to establish a context / scope for a group of actions.

Code from the official announcement:

using (var op = this.telemetryClient.StartOperation<RequestTelemetry>("request"))  
    HttpClient client = new HttpClient();  

If you establish this operation context at the beginning of your OWIN pipeline, then all telemetry further down the pipeline will be sent within its scope, providing you with expected correlation. This solves both problems mentioned before, however it introduces a new one, that surfaces when hosting the application on IIS / System.Web.

StartOperation relies on the CallContext. Thanks to this, you can have some shared piece of data you can access at any point down the call tree. However there are situations, where the logical sequence of calls is broken in the OWIN pipeline. This happens when you have a middleware that uses stage markers. One example of such middleware are the ASP.NET Identity and Security packages. This middleware expects to run at a certain point of the System.Web pipeline, which is achieved by subscribing it to corresponding events of the HttpApplication. Unfortunately, this causes the call tree to be broken and the data within CallContext is lost.

AI OWIN Extensions

At this point I would like to introduce you to a library I created, called Application Insights OWIN Extensions. It will hopefully let you solve all the problems mentioned above. Apart from utilizing CallContext, it also stores the OperationId in the OWIN request dictionary. If you have a middleware that uses stage markers, you can restore the OperationId just after its execution:

public void Configuration(IAppBuilder app)

    // some middleare here...

    // now restore the Operation Id context from the OWIN environment dictionary

    // more middleware here...

Since the library had been developed before StartOperation was introduced in Application Insights SDK 2.0, it uses a custom solution for working with CallContext. However currently I'm looking for a possibility to actually use StartOperation concept in the library, while keeping other functionality.

I hope you will find the library useful.

About the author:

Marcin Budny

Team lead of R&D at BT Skyrise. Works with Intelligent Transport Systems (ITS), where he faces problems in terms of equipment and software. He is passionate about the architecture of applications, cloudcomputing and IT systems quality. He constantly searches for novelties on software development. Marcin specializes in .NET technology, however he looks for inspiration in other languages and platforms.

Next Post Previous Post

blog comments powered by Disqus