Introduction
Effective logging in a production environment whether it is a Client-Server application, backend application (such as windows Services), or e-commerce web site, is becoming a common business requirement. Event logging is the heart of any application for debugging, tracing and monitoring the application. Once any application goes into production environment, Event Log is the most effective and the only way to monitor the application and to find out the application failure reasons. It is the fastest way of getting the application failure details only if the logging mechanism is effective and is configurable to suit the business needs. This article is the attempt to provide a simple, configurable and effective logging mechanism to application designers.
In this article, I'll be discussing:
- Most common requirements to write any logger application.
- How to write a simple logging application which uses Windows Event log to log error, warning and information messages.
- Flexibility of the logger application to suit client needs.
The logger application code is downloadable. It uses SQL Server DB to store the Info, Error and Warning Messages. This is to avoid hard-coding of messages in the code which gives flexibility of updating any message without the need to recompile the code.
This application is configurable and protects the client's interest of logging only particular type of messages. It also provides the mechanism to hardcode the message and message type and which will be logged into the Windows Event Log.
Background
I've seen designers and developers struggling for coming up with a proper logging mechanism which gives a proper picture of the application and also is intelligent enough to filter particular type of messages. Here, I'll discuss how to write a logger application in which you can set a log level to filter particular type of messages. This allows clients to filter unwanted messages and protects from being logged into the event log.
Most common requirements to write a logger application
During my experience, I've observed that below are the most common requirements for writing any logger application:
- It should be easy to log the message into log sink without any need of specifying the type of message.
- It should be flexible enough to change the message description without any need to recompile the code.
- It should be possible to hard-code the debug message (useful specifically in case of backend applications like Windows services, which helps for debugging).
- It should have an user friendly interface to sort the messages depending upon type, user, date, source etc.
Easy steps to log the message into Windows Event Log
The easy and simple steps to test the event logger application is just download the code, execute the DB script, and run the code as it is. That's it! The code contains the logger DLL and also the test application to test that DLL. The detailed description is as below:
Step 1: Create the Logging Database
Download and execute the DB script in your application's SQL Server DB. This will create a table (name: Messages) for storing the predefined messages. The script also will create the stored procedures required to retrieve the corresponding message and to log into the event log.
Step 2: Configure the application settings
- In you application configuration file, specify the connection string and
MessageLoggingParameter
.
MessageLoggingParameter
value can be set from 0 to 7, as below:
MessageLoggingParameter
0:-No messages will be logged.
MessageLoggingParameter
1:-Only information messages will be logged.
MessageLoggingParameter
2:-Only warning messages will be logged.
MessageLoggingParameter
3:-Only error messages will be logged.
MessageLoggingParameter
4:-Only information and warning messages will be logged.
MessageLoggingParameter
5:-Only warning and error messages will be logged.
MessageLoggingParameter
6:-Only information and error messages will be logged.
MessageLoggingParameter
7:-All messages will be logged.
- Specify the application Log Name. This will be created as a separate entry on the left side pane of the Windows Event Log.
<add key = "LogName" value="Test Log"/>
- Specify the application source:
<add key = "EventSource" value="My Application"/>
Step 3: Log the message:
Now you are ready to log the message into Windows event log. This is an easy step. Just add a few messages with MessageID, type of message (Error, Information, Warning), and message description, into the Messages table. This creates your message store, which will help you to update any message without the need of recompiling the code, and this will be logged into Windows Event Log. The code to log the message into event log is as below:
Logger logger = new Logger();
logger.Write(3);
logger.Write("This is my message","Information");
Logger class:
Let's see what we are doing in the logger class which is taking care of configuration, message retrieval from DB and logging messages into Windows Event Log.
The Write
method first retrieves the message type and message description from the DB depending upon the MessageID passed to it. The Write
method then creates the Event Log and Event Source if it doesn't exist.
EventLog objEventLog = new EventLog(strLogName);
if(!EventLog.SourceExists(strEventSource))
{
EventLog.CreateEventSource(strEventSource, strLogName );
}
Then the function gets the information about the type of message and client's interest configured in the app.config file whether to log the message or not, and logs it accordingly.
if( (strMessageType.ToUpper().CompareTo("INFORMATION")
== 0) && ( (iMsgLogParam == 1) || (iMsgLogParam == 4)
|| (iMsgLogParam == 6) || (iMsgLogParam == 7)
|| (iMsgLogParam == 8) ) )
{
objEventLog.WriteEntry(strMessageDesc,
EventLogEntryType.Information);
}
However, the steps of taking message details from DB is skipped in the overloaded method of Write
method as the message description and message type is passed by the user.
Conclusion
I really hope the Logger application design and sample code here will be useful for application designers and developers.