Event Logging and Distributed Logging in ASP.NET

Test Results

On running the client on two machines and the server on one we see the typical output on the server as shown below.

Source: UTPAL-NY1:13:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:14:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:15:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:16:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:17:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:18:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:19:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:20:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:21:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:22:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:23:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:24:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:25:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:26:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:27:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:28:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:29:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:30:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:31:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:32:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:33:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:34:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:35:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:36:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:37:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:38:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:39:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:40:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:41:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY2:42:12/18/2002 5:32:21 PM:System.String[] Source: UTPAL-NY1:43:12/18/2002 5:32:21 PM:System.String[]

Enhancements to the library

For production purposes this library needs to be enhanced in the following way.

The remote calls to the global event log must be wrapped in an asynchronous remote call. This is important so that local logging calls can finish in a deterministic time instead of waiting for the remote call to finish.

Alternatively, the flushing of the logs to the global log can be done in a separate thread while the local event log call returns immediately. Another approach would be to have a producer-consumer model where a background thread continuously flushes the buffer. In this implementation the buffer needs to be implemented as a FIFO queue where the local event logger writes to the tail of the queue and the buffer flushing thread logs the events to the global server by removing events from the head of the queue. The priority of this flushing thread can be adjusted depending on the length of the buffer.

Lastly, the global log can write to a whole set of LogListeners (which need to be defined). These can be dynamically added at runtime. The same strategy can also be applied to the local event log.

Conclusion

We saw how to use the standard event logging API of .NET to log events to the Windows event log. These classes can be helpful in monitoring applications and tracking down errors. However, the built-in event logging API has a few drawbacks, therefore we created a small library to alleviate these that allow multiple machines to log to a central event log that can have one or more event stores.

About the Author

Utpal Chakraborty is Manager, Software Engineering at Organic (http://www.organic.com). He has extensive experience in developing enterprise applications using Microsoft and non-Microsoft technologies. He can be reached at uchakraborty@organic.com.