|
Project Information
Featured
|
Introductionlucene-log4j solves a recurrent problem that production support team face whenever a live incident happens: filtering production log statements to match a session/transaction/user ID. MotivationIn production we often find distributed systems colaborate with each other in order to provide services. As messages travels through these systems, they will usually carry an unique ID that identifies the main transaction (which makes sense when a message results in several child messages to be fired, such as a distributed search). Now you can log this ID that you associated with the current thread in your server logs along with other information that you consider useful so you can later come back to the logs in order to find out what happened actually.
The problemAs you are most probably aware, in a busy multi-threaded application server the log statements written in one thread quickly entangles with the ones written by other threads. So in order to filter the log to show only the log statements related to a certain ID you will need to write some tools. Some of them are:
My approach
To solve the problems stated above (sequetial operation and space/network requirements), I came up with this in-site solution which consists on building a searchable Lucene index in the application deployed on application server. It works by extending Log4j's RollingFileAppender with Lucene indexing routines. Then with a LuceneLogSearchServlet, you get access to your log using web frontend. This solves the former problems and has the benefit of distributing the load on search. Combined with a messaging middleware, e.g. Mule ESB, it's possible to combine the search results and present it all together. Limitations
WARNING: log file has been rolled over! Don't trust on the search results and re-run the quey
Tips
|