Scott Hanselman’s latest podcast on end to end tracing got me thinking about the need to capture tracing information.  Sometimes, despite our best effort, we are unable to reproduce issues encountered at customer sites.  When that happens, what can we do?  Collect some debugging/tracing information, that’s what!  If you are lucky, this will help you pinpoint the problem in the deployed system.
In our system, we can turn on different levels of debugging for the various components of the system.  Simply edit a text file, add a few simple lines, restart the program and reams of data gets collected.

What is wrong with this picture you might ask?

Two things:

  1. It requires editing a file – even if it’s simple, even if you can coach a user, they don’t like it
  2. It requires restarting the program.  Sometimes, this is simply not acceptable.

Remember, we’re not talking your development environment here, but a live, running system!

In our case, we decided to put a simple radio button group with 4 options:  No tracing, low, medium and high tracing.

Yes, we loose granularity on controlling which components trace, but the trade-off is more than worth it:  No files to edit, and no system restart.  Makes the customer happy, and gives the engineer the information they need.  What more could we ask for?