So you’ve got this great web application. It’s being used by thousands of users. The code is written perfectly (or so you think). It’s just pure magic.
Then there’s this one page in your application. You know, that one you’ve written on a Sunday morning, hungover from last night’s party. That page is working at the same speed you were probably coding that morning and throws up more errors than… well you get the picture. How’re you going to monitor this in production and catch those exception?
Here comes Azure Application Insights! In this post I will tell you about some of my favorite Application Insights features and by doing so I’ll try to convince you to start using it too.
Before I start about how good Application Insights is, I’ll first give you an overview about some of its alternatives I’ve used in the past.
Elmah (Error Logging Modules and Handlers) is used, as the name says, to log errors.
Elmah logs almost nearly all unhandled exceptions. These can then be viewed in a webpage or/and send within an email.
As you might have noticed there’s no monitoring with Elmah, just error logging. So this would help you fix those nasty errors in your application, but you’d still have no clue about how slow your application is.
New Relic is quite a broad tool which can be used mainly to monitor your application, server and other services.
It’s has an enormous amount of features and reports, some more clear than the other. The problem I had with New Relic is that it showed too much and I couldn’t really understand the bigger picture of what I was seeing. I also had the feeling it didn’t quite work completely as it should with Azure. Which is normal since we’re talking about two different companies.
Of course there are also other tools. But I didn’t get the chance to test them out yet.
How to get started
Getting started with Application Insights is easy.
You can start by either going to the Azure Portal en create an App Insights service, or you can even do it from your Visual Studio.
Besides .NET application, Application Insights can also be used within non Microsoft applications. WordPress for example has a plugin which can insert Application Insights into your website.
This is already one of it’s best features, it’s so easy to setup and you’ll be able to start using it in no time. It’s also free (depending on how long and how much data you want to store), so why not use it if you’re already on Azure?
More info on how to get started can be found in the Sources section below.
Every application will throw an error sooner or later. The question is, how will you handle them? You can just ignore them until users start to complain. You could use Elmah to email them to a certain mailbox or show them on a certain webpage. The latter could impose a security risk while the other would require you to setup a mailbox. Both however will not be able to show you in detail what happened. At best it’ll show you were the code failed, but that doesn’t always tell you the complete story. With Application Insights you can combine all data, from a certain point, to analyze what really happened without having to do any special setup.
This is probably one of my favorite features. It covers all basic metrics you want to monitor:
This feature will send you an email if one of the above checks is triggered. So even if you don’t care that much about most monitoring features in Application Insights, Azure will monitor it for you and notify you when something is going wrong.
Combine this with the server errors and you have it all covered.
Always On with Free and Shared plans
As you might know, the “Always on”-functionality is only available in App Services from a Basic-plan and up.
With Application Insights Availability it is possible to setup a ping test. This will make Application Insights ping your website at preset intervals with a maximum of fifteen minutes. By doing this, your application has no opportunity to go idle and thus you have the same functionality as “Always on”.
Make sure you’re not connected to Application Insights (through your Instrumentation Key) while you’re debugging on your local computer. Data is still being send and will be charged. And because you’re debugging, this data can be a quite large and will pollute the data you actually want to see.
I just leave the Instrumentation Key empty so the application does not know which Application Insights service it needs to connect to.
This is only a small part of what Application Insights can monitor for your application or website. There are a lot of other features with new ones being added on a regular basis.
So go and check it out to make sure you know what your application is doing!