Recently Azure team announced the availability of SDK 2.5. You can read the release notes here: http://msdn.microsoft.com/en-us/library/azure/dn873976.aspx. One of the major change that was done in this release is related to diagnostics. In this post we will talk about diagnostics changes in the latest SDK.
What You Get
First let’s talk about the new stuff you get in the latest version of diagnostics.
Diagnostics Library 1.3
This is the latest version of diagnostics client library. Previous version of the library was 1.0. There was a 1.2 version of the library as well but you need not worry about it now.
Support for ETW Event Source
This is a big improvement in the diagnostics. In version 1.0, you’re somewhat restricted with what kind of diagnostics data you can persist and the structure of that data was pretty much decided for you. With ETW Event Source, you can define your own diagnostics data and have diagnostics engine take care of persisting that in Azure Storage for you.
To give you an example, let’s say you want to trace a particular request in your application with some custom fields. Moreover you would want querying capability on these custom fields. It was not possible with diagnostics 1.0. With the latest changes, it is certainly possible to do so. For an example, please see Step 2 on this page: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/.
Diagnostics now use Azure Extension model
While 1.0 version of diagnostics was a Plugin model, the latest version of diagnostics make use of Azure Extension model. What this means is that you can now turn on diagnostics or update your diagnostics configuration without redeploying your code. One of the ways to accomplish this is by using Azure PowerShell Cmdlets.
Consistent diagnostics story for both Cloud Services (PaaS) and Virtual Machines (IaaS)
This again is a huge improvement. It makes it super easy for you to migrate your code running in Azure Virtual Machines to run in Azure Cloud Services as far as diagnostics is concerned. Furthermore diagnostics management becomes consistent across your applications running in both VMs and Cloud Services.
What’s Taken from You
Now let’s talk about what’s taken from you in the latest version of diagnostics.
No Diagnostics in Compute Emulator
IMHO, this is the biggest drawback of this release. I have found compute emulator extremely helpful when doing development locally before deciding to push the code in the cloud and losing the ability to view diagnostics data in the emulator is a big pain. This becomes more painful when you are making use of custom diagnostics feature of Azure diagnostics where you can push arbitrary data into Azure Storage by piggy backing on diagnostics infrastructure (which we make use of a lot in Cloud Portam). So if you depend on Azure Diagnostics in the emulator, you may want to think hard before upgrading your solution to SDK 2.5.
Diagnostics configuration in code is no longer supported
Long time back, only way to configure diagnostics was through the code written in your Web or Worker role’s OnStart() method. After that came diagnostics.wadcfg file to decalaratively define diagnostics configuration (though code based configuration was still supported). With SDK 2.5, code based configuration is gone. Assuming you have been keeping up the SDK releases and your code makes use of relatively latest version of SDK, this may not be a big deal.
This however creates a problem when you want to do an on demand transfer of diagnostics data. Consider the scenario where you are asking diagnostics engine to periodically push the data it holds in its buffer but then to be on the safe side you want the capability to flush this buffer into Azure storage on demand (say when the role is shutting down). With SDK 2.5, it is not possible. So if you depend on this functionality, you might be better off holding.
Upgrading From SDK 2.4 to SDK 2.5
The process of upgrading your Cloud Services from SDK 2.4 to 2.5 is rather painless and seamless. The SDK team has done an excellent job with that. Some of the changes you will notice if you upgrade your solution:
- Diagnostics reference changes from 1.0 to 1.3. You can find the latest version of “Microsoft.WindowsAzure.Diagnostics.dll” here on your computer: “C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.5\bin\plugins\Diagnostics”. As an aside, if you’re using Caching, it will also be updated (C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.5\bin\plugins\Caching) along with Microsoft.WindowsAzure.ServiceRuntime.dll (C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.5\ref).
- diagnostics.wadcfg file under your role will be replaced with diagnostics.wadcfgx file. Good thing is that your existing settings from wadcfg file will be migrated seamlessly into the wadcfgx file.
- “Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString” configuration setting will be gone. This setting is used to define the connection string for the storage account where your diagnostics data is persisted. Instead you define the storage account information in “PrivateConfig” section in diagnostics.wadcfgx file. If your code makes use of this “Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString” setting, please make sure to change the code.
- From your ServiceDefinition.csdef file, the following line will be gone under “Imports” section: <Import moduleName=”Diagnostics” />.
Given that diagnostics is significantly different in the new SDK, the recommendation would be not to blindly update your solution to the latest version. Instead, weigh in pros and cons and then decide. Needless to say, if you do decide to upgrade please test as thoroughly as you can.
For us in Cloud Portam, it is really important to have diagnostics support in compute emulator. Thus we are holding off on upgrading. Our hope is that the support for diagnostics in the emulator comes in the next version of SDK.
Summary
That’s it for this post. As always if you find any issues with this post, please let me know and I will correct those ASAP. As far as diagnostics and upgrade is concerned, I’m in a bit of conflicted state. While I like the new features introduced in the latest version, I am a bit saddened by the lack of support in the emulator. Let’s hope things change for better soon.
Happy Coding!
