Know Your Network - The Azure Service Dashboard

Having trouble viewing your Windows Azure Website? In spite of all the inner voices’ assurances, it might not be you.

#

A Bump in the Night

I have had a very positive experience with Windows Azure. It just works. There have been a couple of headaches along the way, but I sort of expect that since my preferred flavour of Azure has been all the juicy bits still in preview mode.

I was awakened by the furnace kicking in at 4am – it’s 18 degrees Celsius below zero here right now – and was struck with some creative flair.  I shot downstairs to my basement office to work on an Asp.Net MVC site that I’m hosting on Windows Azure Websites.

After less than 15 minutes of work (sure the flair was creative, but it was also small) I attempted a push to the cloud.  And, yes, Steve, my tests were all passing. The response:

Internet Explorer cannot display the webpage? Okay, let’s try Fiddler…

The server did not return a response for this request? Le sigh.

The Big Fix. Not.

The thing I’m digging the most about Azure’s tooling is how it’s taking the friction away. When they introduced the “Download Publish Profile” a couple of months ago, it made the process of pushing a web site to the cloud crazy easy. And because your deployment settings (your publish profiles) are now part of your project, you can script this out and push to the cloud from the command prompt or even as part of your build script.

So I thought, “Hey, maybe I somehow mucked my publishing settings up?”.  I’ve been known to…uh….optimize the odd file or two by hand before. I cleaned out my publishing settings through the build menu (Build –> Publish Selection –> Profile –> Manage Profiles) then headed back to my Azure admin portal to pull down my publish profile. I imported it again and hit publish.  To the cloud!  Gold, right? Nope.

So, back to the portal. I knew something was going to be wrong with what I’d just done, so let’s leverage the built-in tooling for Azure: logging, error details and failed request tracing. This was going to give me something for sure.

You set these up on your “Configure” tab from your website dashboard.  Then you can access all the logs via FTP, the details are listed on your dashboard under the Diagnostic Logs heading in your sidebar.

Hit the page a couple times, refresh my stats. Still nada. Here’s what I was seeing from the stats chart:

Yeah, that’s right. No errors, no requests, no failed connections to the DB.  Zilch.  This is exactly what I want to see at any other time in production except when I’m actually getting errors.

Enough with this cloud business…time to kick it old school. I’ve been around the block and have run into similar things on IIS when there was a mal-formed config file.  Visual Studio didn’t have anything for me as far as errors or warnings, so I darted over to W3Schools to validate the document there. This was a long shot as my site was running locally, but I thought it was worth it.  Still, everything checked out and this failure is not due to my tag skills or lack thereof.

I headed back to my web.config and dropped in this classic, hoping it would spice up my error life:

  <customErrors mode=”Off” />

Still no love. I thought I was going crazy.  Technically, that didn’t have any relevance in regards to this problem, but I like to say that every now and then to keep my ego in check.

I muddled around a bit more in vain, determined to figure out what it was I busted.  An hour and a half in, certain that I had crossed all my i’s and dotted all my t’s, I finally decided to open a support ticket.  The menu option for this is on your portal when you click on your account name:

And then the trophy appeared:

You can verify the health of the Windows Azure Platform on the Service Dashboard.  Oh how I wish I had known that two hours earlier.  Check this out:

Guess which overtired, otherwise confident blurry-eyed developer hosts his Website in West US?

The Moral of the Story

I actually didn’t know that there was a service dashboard.  This is great. I’ve now pinned the site to my home screen on my Windows Phone, and the next time I wake up at 4 AM I’m going to check that little baby first before heading down for 15 minutes of Renaissance-style mid-night creativity.  So, I don’t have a moral to share here, just another tool for the war chest.

Before you pull your hair out fixing “your” problem next time, make sure your hosting provider is giving you all the sweet goods first!

Finally, if there are any shiny happy Windows Azure team members reading this, could you please, please add a notification on my dashboard if a service I am using is experiencing stress, a midlife crisis or apparent loss of network connectivity?  Thanks so much!

(p.s. By the time I finished writing this post, the Service Dashboard showed green checks for all my service friends)