Application Insights for ASP.NET 5 – you’re in control

ASP.NET 5 apps can now be monitored for performance and usage with Visual Studio Application Insights. The composability of components in ASP.NET 5 makes it very easy to integrate telemetry modules into your app design in a flexible way. With the feedback you get about the performance and effectiveness of your app in the wild, you can make informed choices about the direction of the design in each development lifecycle.

ASP.NET 5 is a lean framework for building web and cloud applications. Dependency injection is one of the biggest architectural improvements over previous versions, allowing components to be much more independent, composable, and easily isolated for testing.

This composability has made it easy for us to give you, the app developer, much more control over how you put together the different components of the SDK, compared to the Application Insights SDKs for other platforms.

In the Application Insights team, we believe that good telemetry data collection is critical part of your application. When you put a new feature into the app, you need to know how well it works for the users, and whether it causes any performance problems. You’ll use that data to help prioritize and plan future work. So the telemetry should be designed as part of each user story, and then tested, tuned and deployed along with the app.

From this point of view, it’s clear that telemetry is a tool for developers. It isn’t just a runtime add-on that IT pros use for load management. There is a useful role for that kind of telemetry, but Application Insights is primarily concentrated on developers. We’ve designed it primarily as a development tool, with the runtime add-on as a secondary capability.

We’re delighted with ASP.NET 5, because it fits very well with that philosophy. It’s very easy for us to give you a range of parts that you can select and put together under your control.

Let’s see how that works in practice. Setting up Application Insights has four easy steps.

Step 1. Create an Application Insights resource in the Azure Portal. This is where your telemetry is analyzed and displayed.

Get the instrumentation key of the new resource.

Step 2. Add the SDK NuGet package to your project.

In the dependencies section of project.json, add:

"Microsoft.ApplicationInsights.AspNet": "0.32.0-beta4"

In config.json, tell the SDK about your Azure resource:

"ApplicationInsights": {
        "InstrumentationKey": "af2bd99b-5e71-4465-b03a-24c0f377f93e"
}

Or if you’d prefer the configuration to be dynamic, you can add this code to the application’s Startup class:

configuration.AddApplicationInsightsSettings(

        instrumentationKey: "af2bd99b-5e71-4465-b03a-24c0f377f93e");

In Startup.cs, in ConfigureServices, add:

Services.AddApplicationInsightsTelemetry(Configuration);

Unlike the setup for other Application Insights SDKs, adding the SDK doesn’t automatically configure a range of modules to collect different kinds of telemetry. Instead we’re going to let you choose the modules you want.

You can override any default services you want to replace. For instance, you may choose to implement your own telemetry channel to perform sampling or filtering. Just register it in the same method ConfigureServices, and dependency injection will make use it instead of the standard telemetry channel.

Step 3. Enable the telemetry you choose. You can both write your own telemetry into your app, and use the standard middleware components to report basic metrics like number of requests per second or detailed information about a failed request. Middleware is configured in the Configure method of Startup.cs, and it forms a pipeline:

app.UseApplicationInsightsRequestTelemetry();
//Error handling middleware goes here…
app.UseApplicationInsightsExceptionTelemetry();

Request tracking should always be the first item in the pipeline to give you the most accurate timing of the request. Typically exception reporting goes after any error handling middleware and before other middleware. Typical error handling middleware will handle exceptions and thus earlier middleware in the pipeline will never see it. Thus the Application Insights exception reporting middleware should go after the error handling middleware components unless you don’t want to report some exceptions to Application Insights. Again, you are in control of your telemetry and of course you can write your own middleware if you prefer.

Step 4. Enable client-side reporting of usage and browser performance. From your Application Insights resource, you can get a snippet of code that you insert in each web page – typically just by inserting it in a layout page such as _Layout.cshtml. Using dependency injection you can obtain TelemetryConfiguration class that contains your Instrumentation Key. First, inject the telemetry configuration into the layout page by adding this code to the top of the layout page.

@inject Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration     

        TelemetryConfiguration 

And then use the HTML helper method to inject the Application Insights JavaScript snippet just before closing </head> tag and any other scripts:

@Html.ApplicationInsightsJavaScript(TelemetryConfiguration) 

And you’re all set! You’ll be able to see application telemetry while developing the application, while testing it, and when it’s deployed to production. Now you know how it behaves with real users.

As you can see, the Application Insights SDK for ASP.NET 5 application is flexible and easy to configure.

This SDK is an open source project with design discussions, source code and documentation available on GitHub. Get started monitoring your ASP.NET 5 application with Application Insights now, get visibility into the performance and reliability of your application in production and speed up your engineering. We are happy to hear your ideas and feedback. Just file an issue and tell us what you think.