Logging within your Project

 

Contents

• Why Should I Log
• What Should I Log
• Importance of Logging Levels
• Where Should I Store My Log

Why Should I Log

Within a coded project I cannot stress the importance of logging the application’s progress and activity. The language you use is irrelevant in this case because the goal is to be able to check on your application at any given time.  More importantly you WILL need to check on the activity when something goes wrong.

Logging your applications activity becomes even more imperative when the content you are working with becomes more critical. In my experience I have designed systems for branches of the US military, testing systems for universities, and the occasional financial system. In every case I have needed to know what is the current state of a process, or where a process may have failed. Logging has saved me every time.  Let us not forget the classic CYA issues we consultants find us in when something breaks.

What Should I Log

You should log what your application is doing.  That sounds broad, and it is.  Logging your application’s activity can run the gambit of simple status messages to detailed calculations and data operations.  My typical logging considerations are these:

• Start and end points of the application.  If this it is an automated process this is very important.
• Entry and exit within crucial methods.
• Recorded affected record count details. Knowing how many records were affected by an CRUD operation is extremely valuable.  Keeping in mind that when you use database procedures you should consider returning the affected record counts.  In SQL Server it is the @@ROWCOUNT and in Oracle it is the %ROWCOUNT.
• Details on calculations
• Security entry points and audit type of information.  Systems need to be checked not only for coding errors, but also for security and auditing type details.  Keep the basics of who, what, when, and (if possible) why.

Importance of Logging Levels

First of all, let’s answer the question of what Logging Levels are.  These levels of importance that you will assign to your individual log entries.  As you code your log entries within the application, you have to consider how crucial that entry is to the overall stability, reliability, performance of your system.

The typical levels we see in most logging systems like log4net or .NET Tracing are these:

Log Type	Description	Level
OFF	No logging will occur	5
DEBUG	This is a very detailed message that should include stack trace details and code positional information.	4
INFORMATION	This is a message that should just provide simple details. A good example is the entry and exit of a method.	3
FATAL	This is a fatal error that caused the system to end.	2
ALL		1

These are pretty much self explanatory, but it is important to consider frequency. Typically went setting the level of your current log you should consider the environment you are running in.  Of course in a development environment I would push the level to DEBUG, but in a production environment the amount of records created would be far to great.  So I typically set that level at INFORMATION.

Notice that FATAL and ALL are lower in level than information.  This results in all FATAL and messages set as “ALL” to be captured.

Where Should I Store My Log

It is my opinion that if you have the option to store your log in a database that is the ONLY place.  The database option allows you a myriad of sorting and filtering options.  With that said you should consider your space options.  If a database isn’t an option than I would highly suggest a CSV file in a shared folder.  Be sure to put some logic in place to keep your file size down.  I typically keep the file name containing a day or month of the current date.  That way a new file is generated automatically at intervals.