Okay, I admit, this made me wildly overexcited. I was asked by a colleague to add Azure App Insights to a Sitecore (i.e. ASP.NET) website we’ve been building. I’d not really heard of it before, other than vaguely for proper ‘Apps’, not websites. However, I added it – and it blew my socks off.
I started by following this article http://azure.microsoft.com/en-gb/documentation/articles/app-insights-start-monitoring-app-health-usage/
I then refactored my website to wrap any access to the Sitecore.Diagnostics.Log class in my own logging class. I then implemented all the same logging methods as Sitecore’s logging. I added a static TelemetryClient object, though, and then for some classes of message, I also wrote to Azure App Insights.
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Sitecore.Diagnostics;
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading.Tasks;
namespace Example
{
static class LogHelper
{
private static TelemetryClient _telemetry = new TelemetryClient();
public static void Debug(string message)
{
Log.Debug(message);
}
public static void Error(string message, object owner)
{
Log.Error(message, owner);
TrackMessage(SeverityLevel.Error, message);
}
public static void Info(string message, object owner)
{
Log.Info(message, owner);
TrackMessage(SeverityLevel.Information, message);
}
// ... and implement all the other methods as defined in Sitecore.Diagnostics.Log
private static void TrackException(Exception exception)
{
_telemetry.TrackException(exception);
}
private static void TrackMessage(SeverityLevel level, string message)
{
_telemetry.TrackTrace(message, level);
}
}
}
That’s it – only really 3 lines to write into Azure. You could write custom events and data, etc., but I wanted to just catch exceptions and trace high-level messages (warning, info) – and I wanted to leave Sitecore’s logging intact. I did also consider using reflection to haul the current object/method off the StackFrame, but didn’t for now.
And what did I get for this effort? Well, from the website’s live system, I could see any exceptions, timed Sitecore job’s coming to life and running, traffic levels and requests – it is fantastic! So much better than digging through indifferent log files hoping to find some clue.
For example, look at this:
You can see a timer job coming to live at 0900 hours – and can you spot where I pushed an update that fixed a few issues? Yup, shortly before 0900. That’s a fantastic level of detail.
You can also look into logs for more detail:
And follow that through to the original request, etc.. Very cool, lots of detail, including things like the thing making a request (more on that in my next post).
Things that we’ve not yet done (but should):
- You can set up automatic email alerts against various performance metrics – such as the number of Server Exceptions in a given time window.
- You can record the browser load time by inserting some JavaScript into your page (we didn’t do this – yet)
- Review failures from the system – 404s, etc.. I’ve already been keeping an eye on server exceptions.
- Analyse traffic sources – a quick glance shows more traffic from Hong Kong that I might have expected.
Finally – this is what logging, diagnostics and monitoring should be like…
Andy Burns' Blog 
[…] one was a real Sherlock Holmes case. The site I’ve been working on has Azure App Insights monitoring it, and on the live site we started to see lots of exceptions that hadn’t appeared […]