One thing each developer strives for is maintaining less code. I don’t know why anyone would code something more than once, or have to modify code when it could be placed in a configuration file, which is much simpler to modify, not to mention easier to share between projects.
At first, I considered creating a base class for RoleEntryPoint which contained my Diagnostics Configuration for my Windows Azure Projects. Although this would have done a decent job of facilitating my Diagnostics Configuration, it didn’t quite sit right with me as it would need to either load a large set of configurations from the Cloud Service Configuration file which would need to be added to every project, or I would be stuck hardcoding a number of defaults which I deemed to be a good baseline set, neither of these options were very appealing.
Configuration Settings could have been handled by creating a new Project Template within Visual Studio but this still seems like a larger effort than is needed.
I started thinking about how a Windows Azure VM Role would configure it’s diagnostics and started searching around the web of a solution. I’m glad I did as I ended up finding this Golden Nugget. Enter Windows Azure Diagnostics Configuration File:
Web Role: Role [Root] Bin Directory
Worker Role Placement: Role Root
VM Role Placement: %ProgramFiles%\Windows Azure Integration Components\<VersionNumber>\Diagnostics
Windows Azure Diagnostics Configuration File
Schema: %ProgramFiles%\Windows Azure SDK\<VersionNumber>\schemas\DiagnosticsConfig201010.xsd
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
configurationChangePollInterval="PT1M"
overallQuotaInMB="4096">
<DiagnosticInfrastructureLogs bufferQuotaInMB="1024"
scheduledTransferLogLevelFilter="Verbose"
scheduledTransferPeriod="PT1M" />
<Logs bufferQuotaInMB="1024"
scheduledTransferLogLevelFilter="Verbose"
scheduledTransferPeriod="PT1M" />
<Directories bufferQuotaInMB="1024"
scheduledTransferPeriod="PT1M">
<!-- These three elements specify the special directories
that are set up for the log types -->
<CrashDumps container="wad-crash-dumps" directoryQuotaInMB="256" />
<FailedRequestLogs container="wad-frq" directoryQuotaInMB="256" />
<IISLogs container="wad-iis" directoryQuotaInMB="256" />
<!-- For regular directories the DataSources element is used -->
<DataSources>
<DirectoryConfiguration container="wad-panther" directoryQuotaInMB="128">
<!-- Absolute specifies an absolute path with optional environment expansion -->
<Absolute expandEnvironment="true" path="%SystemRoot%\system32\sysprep\Panther" />
</DirectoryConfiguration>
<DirectoryConfiguration container="wad-custom" directoryQuotaInMB="128">
<!-- LocalResource specifies a path relative to a local
resource defined in the service definition -->
<LocalResource name="MyLoggingLocalResource" relativePath="logs" />
</DirectoryConfiguration>
</DataSources>
</Directories>
<PerformanceCounters bufferQuotaInMB="512" scheduledTransferPeriod="PT1M">
<!-- The counter specifier is in the same format as the imperative
diagnostics configuration API -->
<PerformanceCounterConfiguration
counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT5S" />
</PerformanceCounters>
<WindowsEventLog bufferQuotaInMB="512"
scheduledTransferLogLevelFilter="Verbose"
scheduledTransferPeriod="PT1M">
<!-- The event log name is in the same format as the imperative
diagnostics configuration API -->
<DataSource name="System!*" />
</WindowsEventLog>
</DiagnosticMonitorConfiguration>For more information, see the Windows Azure Libarary Article: Using the Windows Azure Diagnostics Configuration File.
I would suggest reading the Section: “Installing the Diagnostics Configuration File” which outlines how the diagnostics configuration file is handled along side the DiagnosticManager configurations.
Happy Clouding!