Diagnostics and Logging in Windows Azure

My MSDN Magazine article on diagnostics and logging in Windows Azure is now available in the June 2010 issue and online.

There was some material that I didn’t have space to include or that I’ve learned since submitting the final revision of this to MSDN in March.   I’ll use this blog entry to capture some of that.

First, Rory Primrose’s blog has a few good posts on performance issues of tracing.  Rory talks about thread-safety issues and getting better performance even in the face of non-thread-safe listeners, and also the fact that the default configuration adds a default listener to put tracing output in the Debug console in Visual Studio (i.e. effectively passing everything that comes through the tracing pipeline to Debugger.Log).

Second, I recommend using a logging framework – either using an existing one or rolling your own.  You’ll get more flexibility in formatting and a single place to extend logging as you discover things you want that it makes sense to put in the framework.  I’ve been playing with a framework from the Microsoft Application Development Consulting (ADC) group in the U.K. called simply UKADC.Diagnostics.  Josh Twist from that group has done a nice job of providing a good overview of using the standard System.Diagnostics features (on which Azure Diagnostics is based) and then showing how to incorporate their open-source library, UKADC.Diagnostics, into that.  I wrote a custom listener for UKADC.Diagnostics which directs the output to the Azure logging listener.  There is more information on creating a customer listener in this MSDN article by Krzysztof Cwalina, although UKADC.Diagnostics provides a base class, CustomTraceListener, that simplifies this quite a bit.  The approach I’ve taken – of writing a UKADC listener which redirects to the Azure listener – may not be the most efficient since it requires an extra level of indirection.  One of the questions I plan to research further and will include in a later blog post is more on performance of tracing, including answering perhaps the most basic question: how much overhead does tracing add to my application if I’ve disabled at run-time the level of tracing being invoked, i.e. if I have a Verbose trace call in a method and I’m only logging errors, how much does it cost to simply get far enough through the trace stack to realize that Verbose traces are disabled?  I’ve not found good information on this elsewhere.

While Azure provides the logging and tracing information you write through the TraceSources in your app, it also provides access to a bunch of system logs (e.g. IIS logs, system event logs, etc.).  There is a good post from Mix on getting IIS logs out of Azure.

Hope you find the article helpful – post any questions here and I’ll try to respond, and I’ll also be posting more as I get the UKADC.Diagnostics working with Azure.