You are reading a MIX Online Opinion. In which we speak our minds. Karsten Januszewski Meet Karsten Arrow

Lab Notes

7Comment Retweet

Adventures With Windows Azure Diagnostics

Dec 4, 2009 In Development By Karsten Januszewski

I recently took the Azure plunge, in preparation for an upcoming Mix Online Service we will be announcing soon. Things went relatively smoothly, but I hit few gotchas, especially when trying to get diagnostics and logging working.  Below is a chronicle of said gotchas, with tips on how to resolve them.

Getting Started

To learn how to use the new diagnostics features in Windows Azure, I’d would recommend checking out the following blog post first. Next, there are some great samples that will help you get started:

1.    The tutorial on Channel9 at http://channel9.msdn.com/learn/courses/Azure/Deployment/DeployingApplicationsinWindowsAzure/Exercise-3-Monitoring-Applications-in-Windows-Azure/

2.    The Windows Azure SDK sample HelloFabric, which you can find as a vb or c# sample under Program FilesWindows Azure SDKv1.0samples-csHelloFabric

There was also a great session about diagnostics at PDC that is well worth watching:

However, even with all these resources, I still had some problems getting going, so I wanted to document my experience below. 

Creating a Store In the Cloud

You have to explicitly create a store for your diagnostic information in the cloud. This was confusing to me, because you don’t have to set up anything when doing diagnostics in the local development environment—your logs get saved to the file system and your trace messages get saved to SQL Express.

To get your diagnostic information saved to the cloud,you need to create a storage account up at http://windows.azure.com.  Note that this is different from SQL Azure. You don’t need to create a SQL Azure database; you need to create a storage account under the Windows Azure tab.

Once you create your storage account,you need to note the access key and then create a new connection string for your diagnostics store. It’s tricky to find, but Visual Studio provides a nifty dialog to help you do so. (This is explained extremely well in Exercise three of the tutorial on Channel9 that I mentioned above, so be sure to read it.)

Once you change your connection string, all your diagnostics will be saved to the cloud instead of to local storage, even when you’re doing local development.  It’s easy to flip your connection string back to the development connection string if you like, so you don’t pollute your store with development diagnostics.

Transferring Diagnostics and Logs to the Store

Once you set up your store, you need to change your application to transfer its diagnostics and logs to the store itself (Again, see the tutorial).  To do this, first add some code to the constructor of the WebRole or WorkerRole. Then, if you want to log failed requests, update your web.config file. Finally, use System.Diagnostics.Trace.TraceError(), .TraceWarning() or .TraceInformation() if you want to output diagnostics from within your code,

Viewing Diagnostics Information

Seeing the diagnostics information was another problem I ran into.  I had a store in the cloud, but couldn’t get at the data in the store!

There are APIs that let you get at this data, but you may not want to write code. I found a few tools that helped me get around this: one is http://myazurestorage.com/. It’s nifty, but you can’t see blobs, which is how the IIS logs are stored. That’s a show stopper for me. The Codeplex project has a slightly better tool, http://azurestorageexplorer.codeplex.com, but it also some issues with dealing with blobs. I finally found http://www.cerebrata.com—a really great tool that’s excellent for downloading blobs, as well as reading the diagnostic trace information from my service.  Definitely check this tool out!  Word on the street is that they will be releasing a new version soon with even more features, making this an essential tool when working with Windows Azure.

Getting Everything to Work

The last problem I had was getting everything to work. Once everything was running in the development environment but saved to the cloud, I upgraded my service to production in Azure.  Nothing worked. Ultimately, I deleted and recreated the service. This did the trick. Even in the cloud, sometimes a “reboot” is the only answer.

I’m now set! I can access my IIS logs and get at the diagnostic trace information peppered throughout my code.  Nice! Thanks to everyone who helped me up on the active and helpful Windows Azure forums.

Follow the Conversation

7 comments so far. You should leave one, too.

Karsten Januszewski Karsten Januszewski said on Dec 7, 2009
Matthew Kerner Matthew Kerner said on Dec 21, 2009

Thanks Karsten for putting together this post - you covered a few key steps that anyone who wants to use WA Diagnostics will need to remember.

In addition to Cerebrata''s Cloud Storage Studio, I also demonstrated Cloud eXplorer and Table eXplorer from Clumsy Leaf during the PDC talk on Diagnostics.

-Matt

Offbeatmammal Offbeatmammal said on Apr 12, 2010

Thanks for the hint about "rebooting" the service.

I spent a chunk of today wondering why the heck it was working in local storage, working running on the local fabric writing to cloud storage but.... as soon as I deployed it stopping.

Karsten Januszewski Karsten Januszewski said on Apr 21, 2010

Here''s a very simple blog post to get you up and running:

http://www.azuresupport.com/2010/03/getting-started-with-windows-azure-diagnostics-and-monitoring/

Also, this just got me: be sure to update your call to start the diagnostics passing your config:
DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

instead of the boilerplate:

DiagnosticMonitor.Start("DiagnosticsConnectionString");

Prada Sunglasses said on Apr 25, 2012

Very good brief and this post helped me alot. Say thank you I searching for your facts.

Coach Bags said on May 19, 2012

Incredibly inspiring article, Thank you !?!

Lanvin Sneakers said on May 24, 2012

One of the best sites for relevant facts on this niche !?!