This series of blog posts will tell you everything you need to know about application insights.

Part 1: The Basics
Part 2: Is Application Insights really that “easy to add”?
Part 3: Is Application Insights really that “easy to use”?
Part 4: Application Monitoring with Application Insights
Part 5: Troubleshooting Failures with Application Insights
Part 6: Troubleshooting Performance Problems with Application Insights
Part 7: Availability Monitoring and Web-Testing with Application Insights
Part 8: Extending the Power of Application Insights with Glimpse and PowerBI

Part 3: Is Application Insights really that “easy to use”?

If you are instrumenting an application in Visual Studio, you will immediately notice when the application is instrumented. Once the application is executed for the first time, Visual Studio displays a popup that informs you about the events that have been sent. The popup provides links that let you jump to the Application Insights instance in the Azure Portal or go to the Metric Search Window in Visual Studio:

At this point, you are ready to go. You can let the application run and take a look at the data that is collected in the Azure Portal. Depending on the technology and instrumentation, more or less metrics are collected. At a later point in time, you can go back and extend the instrumentation to fit your needs.

The metric browser in Visual Studio lets you search and filter all the events for inspection:

The dashboard in the Azure Portal Application Insights blade already contains charts that show your data and a number of tiles that take you to even more charts:

The initial dashboard after instrumenting my blog.

Custom Instrumentation

With an instrumentation of ASP.NET, for example, you already get a lot of insights into your system. Most of the features are ready to use. However, if you need more (or work with a technology that needs manual instrumentation), you can always instrument the code manually. The easiest approach is to use one of the SDKs that can be downloaded from GitHub.

From Visual Studio, you can get the Application Insights NuGet Package:

Once the package is installed, the TelemetryClient class provides a number of methods to send data to Application Insights. Instantiating the client and sending data is no more than a call to the constructor and the corresponding methods:

Chose the method according to the type of data you are sending:

• TrackPageView()
• TrackEvent()
• TrackMetric()
• TrackException()
• TrackRequest()
• TrackTrace()
• TrackDependency()

While debugging the output window in Visual Studio shows you all the metrics that are sent to Application Insights. This lets you track exactly what is going on and what kind of events are sent.

Developer Mode

An important feature to know is the Developer Mode. Developer Mode can be enabled by setting the “DeveloperMode” property on the TelemetryClient instance to true. Once Developer Mode is enabled, the TelemetryClient will send the events one-for-one and immediately. This comes in handy during development when you try to figure out what is going on. However, once you move to production you should disable the Developer Mode. With developer mode off, Application Insights will buffer telemetry data and send it in batches. This is of course beneficial for the performance but comes with the drawback that the data in the portal will be delayed.

In the next post we will discuss how to monitor applications with Application Insights:

Part 4: Application Monitoring with Application Insights