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.
static class LogHelper
private static TelemetryClient _telemetry = new TelemetryClient();
public static void Debug(string message)
public static void Error(string message, object owner)
public static void Info(string message, object owner)
// ... and implement all the other methods as defined in Sitecore.Diagnostics.Log
private static void TrackException(Exception exception)
private static void TrackMessage(SeverityLevel level, string message)
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.
- 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…