I spent a few minutes today getting reacquainted with Application Insights. Here’s some links and walkthrus so you can have fun with it yourself. For web dashboarding, I do think it has distinct advantages over Google Analytics etc.
See this article, which – fair warning – I borrowed from pretty heavily in my experiments. You’ll need an Azure account and at least VS2013 update 3.
There’s two ways of going about sprinkling ApplicationINsights pixie dust all over your app. (And no it doesn’t have to be ASP.NET site!)
- Create a new project (or open an existing one).
- R-click on project and select Add Application Insights Telemetry. This will add all the references you’ll need and add some event handlers to your startup code.
Can add App Insights Status Monitor to an existing app (NuGet?) Executes NuGet, updates web.config, and restarts.
The other fancy way is on creation. Note, adding it to your site is now the DEFAULT! Redmond won’t rest till all your dashboarding/alerts are showing up in one central place.
From your Azure Portal:
Click New, Application Insights. You can browse to your site from here as well.
Once you’re viewing the A.I. portal, try clicking on Requests or Alerts to improve your telemetry/charting.
It was embarrassing how easy it was to add availability/performance tests using this site’s walkthrough. In my case, I had the site instrumented: all I had to do was click on the webtests tile in the AppInsights dashboard to create my test:
And wait a few minutes and presto – I had to manually refresh the portal – but I get fancy-dancy availability graphics. It’s drillable and … wow to get this much out of the box is kinda amazing.
Another option is to explore adding telemetry. Click on the Diagnostic Search icon in the portal…
Which opens up a drillable, filterable list of all the telemetry on my app. Including tags.
Go ahead and click on one of those events – I just dare ya. Notice you can drill in specifically by clicking on the three ellipses below the Request Details node to view every field collected:
In this case, using the very cool Filter set to Errors showed me exactly where the issue was – database availability. It even parses log4Net or Nlog traces.Easy peasy!
// Set up some properties:
var properties =
var measurements =
// Send the event:
telemetry.TrackEvent(“endOfGame”, properties, measurements);
Alternately if I wanted to throw errors – this is very powerful as you can navigate between failed requests and exceptions and read the entire exception stack – create a new page called ThrowError or the like and add the following to Page_Load – after adding a using reference to Microsoft.ApplicationInsights in the header:
var telemetry = new
//doing some stuff here
catch (Exception ex)
// Set up some properties:
var properties = new
Dictionary <string, string>
var measurements = new
Dictionary <string, double>
// Send the exception telemetry:
telemetry.TrackException(ex, properties, measurements);
Then I build it out and try hitting that page a few times. Suddenly I get drillable exceptions:
A wonderful overall video is shown here – http://azure.microsoft.com/en-us/documentation/videos/getting-started-with-application-insights/