Cleaning up tracing

I 开发者_StackOverflow中文版have a large application (>50k loc) in C# using NLog for tracing, and the tracing has gotten somewhat out of control. Some libraries embrace proper tracing (correct level / verbosity), others just send everything to Error/Info level.

I need to clean this up in order to make all errors reflect the correct severity. As a result we have essentially disabled production tracing, when I really want to reenable general exception tracing to keep track of production problems.

What is a good workflow for tacking this? Are there any tools to help track down all trace statements in a clean fashion? I am currently planning to use re sharper and find all usages, and just spend some time tackling this.

Update: I wasn't clear here, I am looking for some good guidelines on tracing in general, and perhaps some suggestions on the best way to retool my large code base.

This is what I use (but I use log4net, but I guess its the same)

.trace() - is to be used to record stuff like function entry and exits, and huge datadumps

for(a in l) { trace("List contents: "+ a) }

.debug() - is to print 1 (one) line of information complete when considering a branch. You may have several debug statements in a single function, but not 1 pr line. When you read the debug statements, it should read like a terse version of the
function.

.debug("Checking if current account {} for user {} has more than {} amount", amount);
.debug("Account criteria met for account {} for user {}; making withdrawel of {}", otheramount);
.debug("Account {} debited by {} amount. Transaction key {}");

Every debug line must stand alone, and contain all information required to understand it. Its no good having a line just read "Checking account level", because your next question will be which account? what user? what amount?

.info() - At most 1 or two pr function, and only in the high level scope. Must be data complete.

.info("Withdrawel procecss complete for account {}, user {}, for amount {}");

.warn() - Non critical errors, data complete, so you can pass these to a mailer logger, and check that mailbox once in a while.

.error() - same as warn, but more important. User was actively blocked from achieving his goal, so you want to review those more often.

.fatal() - Should go directly to pager of sysadm, if possible with information about server/machine name.

Aside from this, make sure each class has its own logger, based on that class, so you can easily turn logs on and off for specific areas of the code, even at runtime.