Tracing in Microsoft Azure Cloud Service

Setting Up the Tracing

Since it took me some time to figure out again what to do to see the tracing output of my Microsoft Azure Worker Role in a Cloud Service, here are some hints.

First, read How To Enable Diagnostics in a Cloud Service. Following the step-by-step description solves most of the issues. I think it’s worth mentioning that there is no need to do any coding to enable tracing when following these steps. One just have to add the tracing messages themselves to the code.

Then, I created a new Cloud Service and a new Storage Account in the Microsoft Azure Management portal.

Before publishing the Cloud Services, I changed the size of the VM from the default value “Small” to “ExtraSmall” in the ServiceDefinition.csdef file. This size fits for testing purposes and is way cheaper.

After publishing the service to Windows Azure, I had to adjust the diagnostics settings manually. No idea why Azure was not using the settings of the config files – maybe I missed some. I used the Server Explorer of Visual Studio. Just right-click on the role node in the Windows Azure / Cloud Services tree, and make sure to take the proper deployment slot (production or staging). Then select Update Diagnostics Settings… and set the required values of the Application logs tab page.

Diagnostic Settings

Accessing the Output

To access the output, I use the Server Explorer of Visual Studio too. There is no need to install third-party tool for this.

The trace output can be found under the Storage node. Find the Storage Account created for the Cloud Service and open the Tables node. There should be a WADLogsTable item. If not, check all steps described by How To Enable Diagnostics in a Cloud Service and if you have updated the diagnostics settings. Double-clicking the WADLogsTable item will open the table containing the trace output.

Links

How To Enable Diagnostics in a Cloud Service

Take Control of Logging and Tracing in Microsoft Azure (a little bit outdated, but still helpful)

Azure Execution Models (describes and compares Azure Virtual Machines, Web Sites and Cloud Services)

HowTo: Completely Delete Virtual Machine in Windows Azure

Creating a virtual machine in Windows Azure is quite simple. Open the management console, select the Virtual Machines tab, click New, select the kind of VM, enter some additional data, and wait a while. Then the machine is up and running. Simple!

The deletion seems to be that simple too, but it isn’t. Select the machine to be removed, click the Delete button, confirm, and the machine will be deleted.

As an Azure newbie (as I am at the time of writing), one should read the confirmation question carefully. Besides asking if the VM should be really deleted, it states “The associated disks will not be deleted from your storage account.”

Well, not so bad, one might think, I’ll delete the disk from the storage by myself. Just switch to the Storage tab, select the account, switch to the containers tab, open the vhds, select the VM’s vhd, press the Delete button, confirm … and get stuck. Azure cannot delete the vhd, telling “Blob ‘Vm.vhd’ is in use as virtual machine disk ‘VM’, so the blob cannot be deleted.”

To delete the vhd, one has to go to the Virtual Machines management, select the Disks tab, and delete the disk here. Deleting the disk, one can (and in this case should) delete the associated vhd too, selecting the appropriate option. Only then the vhd is also deleted from the storage. In case you decide to obtain the vhd, you can remove it later from the Storage management tab.

Keeping the disk has one big advantage: it helps you to save money. A VM can be rebuilt from this disk. In case you do not need a VM for a while, delete it, keep the disk, and rebuild the VM when needed.

You should also take a look at the Cloud Services tab of the management console. Azure creates, from what I saw, a cloud service every time a virtual machine is created. The cloud service, of course, is not deleted when the VM is deleted. One has to delete it separately.

Create a SQL Azure Database using SSDT

To get into Microsoft Azure application development, I was playing around with SQL Server Data Tools (SSDT), trying to create a database on SQL Azure.

I started creating a simple database, having two tables with a few columns. As done before with other tools, I was using the extended properties to document the database ‘inline’. The target platform was my local SQL 2012 instance. Deployment went fine, updating after some changes as well.

So the SQL Azure database server was created quickly, and I tried to deploy that database from my local machine to SQL Azure. It failed – of course (I wouldn’t have written a post just to tell you I succeeded 😉 ).

The reason surprised me, but a solution was found very quickly.

The reason why publishing failed is, that, beside others, SQL Azure does not support extended properties.

The solution is posted by Bill Gibson on the SQL Server Data Tools Team Blog in his post Migrating a Database to SQL Azure using SSDT.

I created a Schema Compare file as suggested by Bill, and put a second SQL Server project into my solution, following his instructions – and it worked fine 🙂

Now I have two database projects in my solution. The first one with full featured extended properties to document the database by itself. This one is used to build and update the local SQL 2012 version of the database. And the second one, based on Schema Compare, to be able to convert the SQL 2012 version into a SQL Azure compatible one and build and update the instance on SQL Azure. Of course, one have to take care not to update the scripts of the SQL Azure version, but keep in mind that SQL 2012 is the master.

This works smooth and easy in my simple test environment, because I do not use such things as user defined types (CLR) or XML indexes. Both are also not supported by SQL Azure. And migrating an existing database which uses these feature is not just letting Schema Compare doing the work. In such a case, one has to do some re-work, or probably re-think the decision to move to SQL Azure.

Btw, I think it’s worth to mention that when excluding the Default objects from schema comparison, this does not mean that column default values created by the CREATE or ALTER TABLE statement will be ignored. It seems that only those defaults created by CREATE DEFAULT are ignored. To me this is OK, since the SQL Server books say that CREATE DEFAULT will be removed in future versions of SQL Server anyway.