Logging in Multi-Tier Application

Im working in an Enterprise Project, and im trying to implement good logging using nLog , i was wondering if there is any book talking about best practice for Logging,

as i dont wanna start to log everything and anything without a standard pattern, it would be realy helpful if i can start from where others stoped,

or开发者_高级运维 maybe if someone can provide me info on best practice using nLog....

thanks in advance...

Think hard about everything you think you need to log. In my experience I found that most of the lines that most developers log are in fact errors that should have been thrown as exceptions. This often results in flooded logging databases (or mail boxes) that nobody looks at and nobody trusts. In the applications I write, I hardly ever log (and catch) anything (besides of course logging exceptions that bubble up to the top of the call stack).

The few log lines that are left should be written with a clear (and verbose) message that clearly indicate what's happening. When you do this you will hardly need to specify a 'logger per type', a feature that most logging frameworks need. Loggers per type are used to prevent log events from certain types or parts of the system to be processed. However, when you follow the pattern of "log little, throw often", you will find out that you don't need to have a logger per type.

Here is one question from here on SO that is trying to get some logging best practices documented: Logging best practices

Some common themes:

Probably the most common logging practice is to retrieve a logger in each type, based on that type, like this:

class MyClass
{ 
  private static readonly Logger logger = LogManager.GetCurrentClassLogger();

  public void DoSomething()
  {
    logger.Info("Doing something");
  }
}

This you allows you a great degree of flexibility in configuring and controlling your logging. If your namespaces are logically laid out, you can easily turn logging on or off or set it to a particular level for a given class, namespace, part of a namespace, etc.

If you wrap the logger, be careful and wrap it correctly. See this post for some (not necessarily definitive) discussion about logging abstractions. Some important issues to consider when wrapping: Do you want to maintain call site info? Think twice about making a single static logger that does not give you the ability to configure logging differently for different areas of your code.

Hope this helps.