Configuration Changes to Windows Azure Diagnostics in Azure SDK v1.3

Note that I added an important advisory to this post on 1/26/2011. See below.

The configuration of Windows Azure Diagnostics (WAD) was changed in the Windows Azure SDK v1.3 release. This post is a follow-on to three earlier posts on Windows Azure Diagnostics – overview, custom diagnostics and diagnostics management – and describes how WAD configuration is affected by the Azure SDK v1.3 changes.

WAD is implemented using the pluggable-module technique introduced to support VM Roles. The idea with pluggable modules is that various Azure features are represented as modules and these modules can be imported into a role. Other features implemented in this way include Azure Connect and Remote Desktop.

Service Definition and Service Configuration for WAD

WAD is added to a role by adding the following to the role definition in the Service Definition file:

<Imports>
  <Import moduleName=”Diagnostics” />
</Imports>

The Azure Diagnostics service needs to be configured with a storage account where it can persist the diagnostic information it captures and stores locally in the instance. This has traditionally been done using an ad-hoc Service Configuration setting typically named DiagnosticsConnectionString. The pluggable Diagnostics module expects the storage account to be provided in a configuration setting with a specific name:

Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString

Note that this setting does not need to be defined in the Service Definition file – its need is inferred from the Diagnostics module import specified in the Service Definition file. The following is a fragment of a Service Configuration file with this setting:

<Role name=”WebRole1″>
    <Instances count=”2″ />
    <ConfigurationSettings>
       <Setting
          name = “Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString”
          value=”UseDevelopmentStorage=true” />
    </ConfigurationSettings>
  </Role>

Configuring WAD in Code

After the Diagnostics module is added to a role, the Azure Diagnostics service is started automatically using the default configuration. There is no longer a need to use DiagnosticMonitor.Start() to start the Azure Diagnostics service. However, in a somewhat counter-intuitive manner, this method can still be used to modify the default configuration just as before. This is presumably to ensure that existing code works with only configuration changes.

A more logical way to change the WAD configuration is to use RoleInstanceDiagnosticManager.GetCurrentConfiguration() to retrieve the current configuration and then use RoleInstanceDiagnosticManager.SetCurrentConfiguration() to update the configuration. There is a new element, <IsDefault>, in the wad-control-container blob containing the WAD configuration for an instance which is true when the default configuration is being used.

The following is an example of this technique:

private void ConfigureDiagnostics()
{
    String wadConnectionString =
       “Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString”;

CloudStorageAccount cloudStorageAccount =
         CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue
         (wadConnectionString));

RoleInstanceDiagnosticManager roleInstanceDiagnosticManager =
        cloudStorageAccount.CreateRoleInstanceDiagnosticManager(
        RoleEnvironment.DeploymentId,
        RoleEnvironment.CurrentRoleInstance.Role.Name,
        RoleEnvironment.CurrentRoleInstance.Id);
    DiagnosticMonitorConfiguration diagnosticMonitorConfiguration =
        roleInstanceDiagnosticManager.GetCurrentConfiguration();

diagnosticMonitorConfiguration.Directories.ScheduledTransferPeriod =
       TimeSpan.FromMinutes(5d);

diagnosticMonitorConfiguration.Logs.ScheduledTransferPeriod =
       TimeSpan.FromMinutes(1d);

diagnosticMonitorConfiguration.WindowsEventLog.DataSources.Add(“Application!*”);
    diagnosticMonitorConfiguration.WindowsEventLog.DataSources.Add(“System!*”);
    diagnosticMonitorConfiguration.WindowsEventLog.ScheduledTransferPeriod =
       TimeSpan.FromMinutes(5d);

PerformanceCounterConfiguration performanceCounterConfiguration = new
       PerformanceCounterConfiguration();
    performanceCounterConfiguration.CounterSpecifier =
       @”\Processor(_Total)\% Processor Time”;
    performanceCounterConfiguration.SampleRate =
       System.TimeSpan.FromSeconds(10d);
    diagnosticMonitorConfiguration.PerformanceCounters.DataSources.Add
       (performanceCounterConfiguration);
    diagnosticMonitorConfiguration.PerformanceCounters.ScheduledTransferPeriod =
       TimeSpan.FromMinutes(1d);

roleInstanceDiagnosticManager.SetCurrentConfiguration
      (diagnosticMonitorConfiguration);
}

UPDATE 1/26/2010 Note that while this works fine for an existing configuration there appears to be a problem when used with an initial configuration. The problem is that the configuration returned by a call to DiagnosticMonitor.GetDefaultInitialConfiguration() is more extensive than the actual default initial configuration inserted in wad-control-container when the Azure Diagnostics Service starts up. It is the latter that GetCurrentConfiguration() returns. The difference I noticed is that the configuration returned by GetDefaultInitialConfiguration() contains three IIS Directory elements while the actual default initial configuration has only one. I raised this as a problem on an Azure Forum thread. Adam Sampson responded to confirm that this is a bug in Azure SDK v1.3 affecting only web roles.

UPDATE 12/6/2010
It is now mandatory that https be used when specifying  a connection string to Azure Storage. This is because the Azure Agent is started before you can specify programmatically that an insecure connection is to be used. The Diagnostics Agent crashes if an insecure connection has been configured. Note that this does not affect development storage.

UPDATE 1/11/2011
Deleted an unnecessary line of code. (Thanks to Andy Cross for pointing it out.)