In this part of the series, I am going to talk about instrumenting diagnostic features for cloud services (web and worker roles) with a custom trace listener implementation in respect to new Windows Azure SDK for .NET (April 2013, version 2.0).
Before starting the implementation, I would suggest you to get an overview of the new SDK. A perfect resource for this would be Scott Guthrie’s blog here. As you can see, one of the areas improved noticeably since v1.8 is diagnostics and key items of which are:
- Built-in diagnostic features for Azure web site enhancements
- Being able to diagnose cloud services directly from Visual Studio
- Being able to change diagnostic configuration settings while application running.
In .NET world, to diagnose and monitor an application, you need to implement a listener that listens the source which is the application itself for events (debug, trace, etc.) and a writer that persist the messages that captured through the listener to intended path (file, database table, storage table, etc.).
All (custom or built-in) listeners are derived from System.Diagnostics.TraceListener. I am going to implement a table storage listener, as name implies, it will outputs the captures to an Azure storage table. Here is the whole class implementation:
What we do here, in summary:
- created a storage table
- converted captured trace information(trace event cache, type, message, etc.) to a TableServiceEntity object called LogEntry,
- then overrided Flush functionality that persists the trace information in table service entity collection to the storage table created in step 1
And now time to add the listener:
In this code block, we do construct the TableTraceListener with 2 strings:
- connection string: set in the service configuration file pointing to the storage table created step 1 above. This is set to “UseDevelopmentStorage=true” when run locally (pointing to local development storage).
- table name: the name of the table created in step 1 above.
Nothing much to say here.
Please note that web role and associated web application run on different processes. Therefore, you need to add the listener in both places.
One picture says a million words, so does here:
… and Show Time
All I need to do now, in order to have diagnostic feature enabled in my solution, is to call ToDoCommon.Util.ConfigureTraceListener(diagConnection, tableName) from the method “OnStart” of the role entry point classes of each role (web and worker) and from global.asax. Below, global.asax is shared:
To test the solution, I have created a dummy page and called the trace functionality from a method:
And the result confirms the success!
In this post, I have implemented a custom trace listener that captures the diagnostic events (trace, debug, and trace source) in the application and writes to a Windows Azure storage table. Advantages of this custom tracing are being able to implement the instrumentation the way you want (lighter perhaps) and being able to define the table name yourself.
Please note that the code blocks shared here are for demonstration purposes; I would suggest you to review your needs (trace switch, buffering, application monitoring capability, etc.) before using them in alive systems. Additionally, I do recommend investigate the configure before customization approach which I will be talking in my next post. Stay tuned