Logging Best Practices

These are couple of good links I came across on logging best practices – One & Two. I have been using Log4Net for all my projects though Logging Application Block from Enterprise Library seems to be equally good. There is a full fledged war out there between two, but I normally don’t see a major motivation to move to latter. Log4Net has got many trace levels which you can flip through your config file – FATAL, ERROR, DEBUG, WARN & INFO. They start from most limited logging to maximum.

Normally I see myself using ERROR & DEBUG only most the time as it’s hard to communicate with developers when they have to draw line between others. My minimum instructions (though not enough, see post script at end of this post) are

1) Use ERROR LEVEL for all exceptions & ensure that hook into unhandled execptions
2) Use DEBUG level to note entry & exit of each method (some people also prefer to log each input to the method as well). This one needs to be more contextual with revlevant information to your domain as simple entry/exit you can retrive from exception’s stack trace as well. Some people use this to find performance bottlenecks in their system during production.

I will briefly elaborate steps to get started with Log4Net for above:

1) Add reference to log4net.dll into your project (This is required per project).

2) Modify your config file to add a log4net configsection & specify various appenders. This config is the for the main projects not class library projects. E.g. you have Presentation (ASP.NET) & Data Access Layer (C# Class Library) only web.config of your presentation project should be altered.

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<configSections>
<!–This is a must addition–>
<section name=”log4net” type=”log4net.Config.Log4NetConfigurationSectionHandler,log4net” />
</configSections>
<log4net>
<appender name=”RollingFileAppender” type=”log4net.Appender.RollingFileAppender,log4net”>
<param name=”File” value=”C:\\HRESWeb.log” /><!–File where the log should reside–>
<param name=”AppendToFile” value=”true” />
<!– FOR DATE BASED ROLL BACKUP –>
<param name=”rollingStyle” value=”Date” />
<param name=”datePattern” value=”yyyyMMdd” />
<layout type=”log4net.Layout.PatternLayout,log4net”>
<!–Pattern to add timestamp, type, etc.–>
<param name=”ConversionPattern” value=”%d [%t] %-5p %c [%x] – %m%n” />
</layout>
</appender>
<root>
<level value=”ERROR” /> <!–Just change the level to DEBUG for informative logging–>
<appender-ref ref=”RollingFileAppender” />
</root>
</log4net>
</configuration>

3) Add an entry in the AssemblyInfo.cs of the project whose config you edited in the second step.

[assembly: log4net.Config.XmlConfigurator(ConfigFile = "ConsoleApplication7.exe.config")]
or for Web.config
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "Web.config")]

4) Start logging

Normally you would create a static ILog Object per class by specifying the class type as parameter & then use Debug & Error Methods for Logging

static readonly ILog log = LogManager.GetLogger(typeof(Program));
log.Debug(“Debug Message”);
// No need to check if Debug level is enabled. Log4Net does that internally
log.Error(“Error Message”);

// A sample method with minimum features
public void SomeMethod()
{
try
{
log.Debug(“Entering”); // Add your contextual information here e.g. patient you processing, claim you working
//… Do Something
log.Debug(“Exiting”); // Contextual information here as well
}
catch (Exception ex)
{
log.Error(“Description : “, ex);
throw; //Don’t forget this
}
}

Logging is also normally implemented via AOP (I had posted a similar article using Unity on CodeProject, though this one deals with transactions).

Also I would recommend that exceptions are also posted in the Windows Event Logs (you can create a category for your application), the motivation being that this increases visibility & is easy for admins to locate them instead of wading through your text, Udi organizes the same thought here.

P.S. An effective way to find out how good your logging is, ask developers to debug without breakpoints during development. If they can do it just by looking at log file, you are on your way, else you might have to get ready for post production nightmares.