Tracking down bugs in distributed systems can be really difficult. One of the technologies we’re using in Indigo to help make this easier is known as “E2E Tracing” (for End to End Tracing). Of course, this technology is only as good as the traces that a system emits. In Beta 1, we weren’t so good about our traces, but in the past few months we’ve made a concerted effort to improve them. And we need your feedback on what is easy to track down and (just as importantly) what was a pain in the butt to figure out. I recommend starting at “Warning” level. Verbose traces are very, well, verbose and can often be hard to navigate through.

Indigo also includes a Trace Viewer (svcTraceViewer.exe) which allows you to make heads (or tails) of the Xml files that are generated. Again, feedback on the tool is highly encouraged.

Here’s a sample config file snippet that will enable tracing in Indigo Applications and will generate Xml file with the traces.

The generated file can then be opened with svcTraceViewer.exe

<configuration>
 <system.diagnostics>
  <sources>
   <!-- The 'switchValue' determines the level of traces that will
             be outputted, e.g. 'Verbose', 'Warning', 'Error', etc -->
   <source name="System.ServiceModel" switchValue="Warning, ActivityTracing"
                 propagateActivity="true">
     <listeners>
     <clear />
     <!-- The 'initializeData' attribute determines to which file
              the traces will be written -->
     <add name="xml" type="System.Diagnostics.XmlWriterTraceListener"
                initializeData="e2eTraceTest.xml" />
     <!-- To log to a Console, use this instead of previous Node:
     <add name="console" type="System.Diagnostics.ConsoleTraceListener" />
     -->
    </listeners>
   </source>
  </sources>
  <!-- Setting he 'autoflush' attribute to 'true' ensures that the trace
            sources flush to disk after each trace -->
  <trace autoflush="true" />
 </system.diagnostics>
</configuration>