Windows Azure Diagnostics (WAD) is built upon Event Tracing for Windows (ETW). To get the most out of WAD and future Azure product offerings you need to understand and use ETW. Here is a little ETW primer and how it relates to WAD:
1. ETW is the efficient kernel-level tracing facility built into Windows. Microsoft products leverage ETW extensively including Windows Azure Diagnostics. Here is ETW’s architecture:
[Image from http://msdn.microsoft.com/en-us/library/aa363668(v=VS.85).aspx]
2. .NET has a legacy tracing capability from .NET 1.1 within the System.Diagnostics namespace implemented in the Trace, Debug, Switch, TraceListener, and derived classes. This legacy capability was built without ETW integration and has some performance issues.
3. To improve tracing performance .NET 2.0 enhanced the Diagnostics namespace by adding the TraceSource and SourceSwitch classes. TraceSource is the preferred, best performing way to trace information from .NET code; no not use Trace or Debug.
4. To integrate .NET tracing with ETW, .NET 3.5 added the System.Diagnostics.Eventing namespace with the EventProvider and EventProviderTraceListener classes. The EventProvider class is an implementation of an ETW Provider shown in the diagram above; it is the gateway from .NET to ETW. The EventProviderTraceListener is the gateway from .NET tracing to the EventProvider class and hence ETW’s efficient and high performance tracing.
5. Here is WAD’s architecture:
[Image from http://msdn.microsoft.com/en-us/magazine/ff714589.aspx; a must read article]
6. The yellow and red portions of the WAD diagram are the .NET tracing discussed in #2 and #3 above. The Microsoft product teams have already added many TraceSources within their framework code and you should do the same within your code. The recommendation is to create at least one unique TraceSource per application or assembly.
7. The black arrows coming out of the red TraceSource portions of the WAD diagram are configured in web.config / app.config. The arrows go to TraceListeners. Out of the box .NET provides around ten TraceListeners. Enterprise Library adds a dozen more in its Logging.TraceListeners and Logging.Data namespaces. The various TraceLiseners have different performance characteristics so pick wisely given your requirements and prefer ones that use ETW.
8. WAD implements a TraceListener called DiagnosticMonitorTraceListener which is shown in the purple box on the diagram above. The listener writes events to WADLogsTable in Azure Table Storage. DiagnosticsMonitorTraceListener is typically wired up in the web.config / app.config as show:
<system.diagnostics>
<sharedListeners>
<add name="azureDiagnosticsTraceListener" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<filter type="" />
</add>
</sharedListeners>
<sources>
<!-- TraceSource.* related settings -->
<source name="WAD_Example" switchName="logSwitch">
<listeners>
<add name="azureDiagnosticsTraceListener" />
</listeners>
</source>
</sources>
<switches>
<add name="logSwitch" value="Information" />
<!-- see System.Diagnostis.SourceLevels -->
</switches>
<trace>
</trace>
</system.diagnostics>
9. Additionally WAD can read from the Windows Event Logs, event counters, custom files, and ETW directly. WAD is one of the ETW Consumers shown in the diagram in #1 above.
10. WAD uses an xpath type expression, which you specify, to filter the Windows Event Logs prior to WAD writing the events to WADWindowsEventLogsTable in Azure Table Storage. If you need to write to the Windows Event Log, the preferred approach is to add an EventLogTraceListener to the config shown above instead of writing to it directly using EventLog.WriteEntry().
For more posts in my WAD series:
http://blogs.msdn.com/b/davidhardin/archive/tags/wad/