Levels of Tracing, Part 2

Continuing from last time where I talked about the different levels of tracing, today covers how to configure trace sources for a particular level and when each trace level should be used.

A simple configuration for tracing combines a trace source with an inline specification of some trace listeners to receive trace events from that source.

 <configuration>
 <system.diagnostics>   <sources>
   <source name="System.ServiceModel" 
           propagateActivity="true" 
           switchValue="Warning,ActivityTracing">
    <listeners>
     <add initializeData="c:\tracelog.svclog" 
          type="System.Diagnostics.XmlWriterTraceListener"
          name="tracelog">
     </add>
    </listeners>
   </source>
  </sources>
 </system.diagnostics>
</configuration>

I've used the System.ServiceModel trace source that provides most of the WCF tracing events with one of the standard text-based trace listeners. For larger configurations, you might build fancier relationships between trace sources and trace listeners that link the two together by reference, with the actual definitions elsewhere. This is mostly useful when you want to collect data from multiple trace sources at a single trace listener.

The configuration options for the System.ServiceModel trace source are the propagateActivity flag, the Warning trace level, and the ActivityTracing flag. Using the propagateActivity flag causes coordinating information to be added to calls so that their relationships can be tracked. The switchValue combines any of the trace levels that I talked about yesterday and optionally the addition of ActivityTracing events.

For a production environment the unfortunate reality is that most people will have to turn tracing off due to the performance overhead. This is something that we're looking to improve for 4.0.

When there's a specific problem, you can drop into the Error, Warning, or Information trace level as needed to get details about what's going wrong. You should probably go down that sequence of trace levels one at a time until you need additional information. An Information or Verbose trace level has so many trace events that it may be hard to find the problem. You'll also very quickly run out of storage space unless the trace listener deletes older data.

For a development environment you might want to try running at the Error or Warning trace levels routinely to make problems easier to track down.

Comments

• Anonymous
  May 05, 2009
  The comment has been removed

• Anonymous
  May 05, 2009
  Thanks James, part 3 will be in a few days.

• Anonymous
  May 17, 2009
  Today's article continues the series on tracing and message logging with a look at the different message

• Anonymous
  May 17, 2009
  Although often associated with event tracing, message logging is actually a separate facility from the