The Windows Azure Diagnostics infrastructure has a good set of options available to activate in order to diagnose potential problems in your Azure implementation. Once you are familiar with the basics of how Diagnostics work in Windows Azure, you may wish to move on to configuring these options and gaining further insight into your application’s performance.
Note that a later version of Windows Azure SDK (v1.4) has been released. This post is compatible with Windows Azure Diagnostics and SDK v1.4.
Here is a cheat-sheet table that I have built up of the ways to enable the Azure Diagnostics using SDK 1.3. This cheat-sheet assumes that you have already built up a DiagnosticMonitorConfiguration instance named “config”, with code such as the below. This code may be placed somewhere like the “WebRole.cs” “OnStart” method. There are two version of how you can do this, which differ in their support for IIS logs. I will list the broadest option first:
If you intend to use IIS Logs:
string wadConnectionString = "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"; CloudStorageAccount storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue(wadConnectionString)); RoleInstanceDiagnosticManager roleInstanceDiagnosticManager = storageAccount.CreateRoleInstanceDiagnosticManager(RoleEnvironment.DeploymentId, RoleEnvironment.CurrentRoleInstance.Role.Name, RoleEnvironment.CurrentRoleInstance.Id); DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();
Note that although roleInstanceDiagnosticManager has not yet been used, it will be later.
If you do not intend to use IIS Logs:
string wadConnectionString = "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"; CloudStorageAccount storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue(wadConnectionString)); RoleInstanceDiagnosticManager roleInstanceDiagnosticManager = storageAccount.CreateRoleInstanceDiagnosticManager(RoleEnvironment.DeploymentId, RoleEnvironment.CurrentRoleInstance.Role.Name, RoleEnvironment.CurrentRoleInstance.Id); DiagnosticMonitorConfiguration config = roleInstanceDiagnosticManager.GetCurrentConfiguration();
The difference between the two approaches is the final line, the instantiation of the variable config
If you debug both, you’ll find that config.Directories.DataSources has 3 items in its collection for the first set of code, and only 1 for the second. In brief this means that the first can support crashdumps, IIS logs and IIS failed requests, whereas the second can only support crashdumps. This difference is a useful indication of what this config.Directories.DataSources collection is responsible for – it is a list of paths (and other metadata) that Windows Azure Diagnostics will transfer to Blob Storage.
Furthermore, once you have made changes to the initial set of config data (choosing either of the above techniques), it is best practise to use the second approach, otherwise you will always overwrite any changes that you have already made.
|Data source||Storage format||How to Enable|
|Windows Azure logs||Table||config.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1D);
config.Logs.ScheduledTransferLogLevelFilter = LogLevel.Undefined;
|IIS 7.0 logs||Blob||Collected by default, simply ensure Directories are transferredconfig.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1D);|
|Windows Diagnostic infrastructure logs||Table||config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Warning;config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1D);|
|Failed Request logs||Blob||Add this to Web.Config and ensure Directories are transferred<tracing>
<add provider=”ASP” verbosity=”Verbose” />
<add provider=”ASPNET” areas=”Infrastructure,Module,Page,AppServices” verbosity=”Verbose” />
<add provider=”ISAPI Extension” verbosity=”Verbose” />
<add provider=”WWW Server” areas=”Authentication,Security,Filter,StaticFile,CGI,Compression,Cache, RequestNotifications,Module” verbosity=”Verbose” />
<failureDefinitions statusCodes=”400-599″ />
config.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1D);
|Windows Event logs||Table||config.WindowsEventLog.DataSources.Add(“System!*”);config.WindowsEventLog.DataSources.Add(“Application!*”);
config.WindowsEventLog.ScheduledTransferPeriod = TimeSpan. FromMinutes(1D);
|Performance counters||Table||PerformanceCounterConfiguration procTimeConfig = new PerformanceCounterConfiguration();procTimeConfig.CounterSpecifier = @”Processor(*)% Processor Time”;
procTimeConfig.SampleRate = System.TimeSpan.FromSeconds(1.0);
|Custom error logs||Blob||Define a local resource.LocalResource localResource = RoleEnvironment.GetLocalResource(“LogPath”);
Use that resource as a path to copy to a specified blob
config.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1.0);
DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
directoryConfiguration.Container = “wad-custom-log-container”;
directoryConfiguration.DirectoryQuotaInMB = localResource.MaximumSizeInMegabytes;
directoryConfiguration.Path = localResource.RootPath;
After you have done this, remember to set the Configuration back for use, otherwise all of your hard work will be for nothing!
Hopefully some of you will find this useful. I will be posting later with more details of custom logging.
I have updated the above to include two ways of initializing the configuration before making changes; as pointed out by Neil Mackenzie, the original approach did not support IIS logs.
In version 1.3 of the Windows Azure SDK, there is a known issue where IISFailedRequest logs are not transferred. This is currently being investigated and there may be a workaround avaiable soon that utilises a powershell startup script to rectify a permissions issue. Thanks to RobinDotNet for pointing this out:
Known Issues in SDK 1.3
RobinDotNet’s forum investigations
Note that the version of Windows Azure SDK v1.4 resolves this problem with IIS Logs not being transferred. This post is otherwise compatible with Windows Azure Diagnostics and SDK v1.4. I will post a new cleaned up version of this post soon.