What are the best practices for including logging using log4net?

Question

I have been told to add “logging” to my code using log4net, the problem is no one can travel in time and see what real world problems the logging will need to be used to solve.

Therefore is there a set of guidlines anyway as to what to log so as to get a reasonable cost/benefit trade off?

Therefore:

What kinds of logging should one add to an application that would be useful later?

(The code uses a lot of WCF, one side is in Winforms, the other side is a “server” that normally run on the same machine)

--

I have excepted AJM's answers to do the useful blog post with lot of comments it points to, but if someone comes up with a nice set of "rules of thumb" I am likely to change the expected answer.

Answer 1

One thing to bear in mind is that whilst your configuration will handle logging at different levels, you may be causing heavy overhead in your log calls. For example:

// some kind of loop
// do some operations
Logger.LogDebug(myObject.GetXmlRepresentation());
// end loop

This will obviously only log the object if you have a logger listening to DEBUG logs, however the call to build the XML object will run regardless of your logging level and could cause some considerable slowdowns.

---

The correct solution would be:

// some kind of loop
// do some operations
if (Logger.IsDebug)
{
    Logger.LogDebug(myObject.GetXmlRepresentation());
}
// end loop

Answer 2

I found this article very helpful: http://blog.codinghorror.com/the-problem-with-logging/

In particular I think a minimalist approach is indeed the way to go. In the past I've tried to log too much but this bloats the code

Also the thinking that the more log entries the better is wrong because it bloats the logs themselves. I now look at loggings main benefit as providing a "foothold" or overview of what is going on. If more detail is needed for particular areas then so be it but the default position should be less is better