Configuring WAD via the diagnostics.wadcfg Config File
Azure 1.3 added the ability to control Windows Azure Diagnostics (WAD) via a config file. The MSDN documentation covering diagnostics.wadcfg explains that the capability was added to support the VM role. The documentation also says to continue configuring WAD via code in OnStart for the other role types.
I instead recommend using diagnostics.wadcfg for all role types to perform the the majority of the configuration and only configure via code when required, such as when using a custom performance counter. This will allow WAD to capture diagnostics prior to OnStart’s execution plus it is easier to maintain a config file than code.
The documentation discusses the location Azure reads diagnostics.wadcfg from; each role type uses a different location. What isn’t explained is how to add diagnostics.wadcfg to your Visual Studio solution such that Visual Studio packages the file into the correct location. Others have blogged about this topic in sufficient detail so I’ll just say that for a web role, the hardest of the three, add an XML file to the root of your web project called diagnostics.wadcfg then change its properties so that “Build Action = Content” and “Copy to Output Directory = Copy always”. “Copy if newer” should work too but I personally prefer “Copy always”.
The sample config XML in the MSDN documentation demonstrates most of the configuration capabilities but WAD fails if the sample is copied as-is into your project. As shown below, the sample XML specifies paths and local storage names which may not exist. Comment out the entire <DataSources> element to get the configuration working. In my next blog post I’ll show how to add configuration settings for custom logs.
1: <Directories bufferQuotaInMB="1024"
2: scheduledTransferPeriod="PT1M">
3:
4: <!-- These three elements specify the special directories
5: that are set up for the log types -->
6: <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="256" />
7: <FailedRequestLogs container="wad-frq" directoryQuotaInMB="256" />
8: <IISLogs container="wad-iis" directoryQuotaInMB="256" />
9:
10: <!-- For regular directories the DataSources element is used -->
11: <DataSources>
12: <DirectoryConfiguration container="wad-panther" directoryQuotaInMB="128">
13: <!-- Absolute specifies an absolute path with optional environment expansion -->
14: <Absolute expandEnvironment="true" path="%SystemRoot%\system32\sysprep\Panther" />
15: </DirectoryConfiguration>
16: <DirectoryConfiguration container="wad-custom" directoryQuotaInMB="128">
17: <!-- LocalResource specifies a path relative to a local
18: resource defined in the service definition -->
19: <LocalResource name="MyLoggingLocalResource" relativePath="logs" />
20: </DirectoryConfiguration>
21: </DataSources>
22: </Directories>
WAD automatically maps the wad-crash-dumps, wad-frq, and wad-iis containers to special folders which only exist in web and worker roles. For VM roles comment out the CrashDumps, FailedRequestLogs, and IISLogs elements.
Finally, there are the various “QuotaInMB” settings. WAD automatically allocates 4096 MB of local storage named DiagnosticStore. WAD fails if the overallQuotaInMB value is set higher than the local storage allocated or if the various “QuotaInMB” values add up to within about 750 MB of overallQuotaInMB. Either:
- Decrease some of the “QuotaInMB” values until the config works.
or
- Add a LocalStorage setting named DiagnosticStore to ServiceDefinition.csdef and increase overallQuotaInMB.
It isn’t documented but the MB’s allocated to DiagnosticStore is a hard limit which WAD can’t exceed. The various WAD quotas are soft limits which control when WAD starts deleting old data. It is possible for WAD to exceed the quotas for a brief period of time while performing the delete.
For more posts in my WAD series: