It has been talked about many, many times, so now it is naturally widely-known that any application, especially one that’s in production, must be monitored. When monitoring, it is important not only to evaluate the current status of the application, but, even more importantly, to predict future potential error situations. It is already standard practice that application programs write log files. These usually contain various information from many different points in the application. Therefore it is very important to process the log files in a way that provides an understanding of what’s going on when things go awry. Unfortunately, as might be expected, the files are usually far from ideally-designed and often contain too many details and too much noise.  As a result, it is actually very difficult to glean much useful information from them. Faced with such a situation, you may often prefer just to select pieces of important information from your logs and see these in real time. In this article, the simple but effective solution for selective monitoring of your Java application logs, in real time, is presented.
You may ask – why Java? The answer is simple – because Java has a powerful log engine, called Log4J. Besides that, the Log4J engine has been ported to other popular programming languages (log4php, log4net, log4cxx, log4js, etc.), so perhaps this same approach can be used with those as well.
Log4j provides many extensions and one of these provides for creating custom appenders. Log4J also has a filtering facility that can be used in custom appenders. Thus, the idea is to create a custom appender with filtering which will selectively get information from your log file and send that information to Monitis. There, it can be shown in tabular and graphical form in order to notify the user if something is starting to go wrong.

We have created the generic custom appender with filtering which receives information from Log4J, filters it according to a user pattern (RegExp) and then sends it to Monitis using the Monitis Open API. The custom appender is wrapped in a Jar file and therefore you shouldn’t make any changes in your application. You can use it as is, without any problem.
All that needs to be done is the following:

• include the log_mon.jar (generic custom appender) in your list of application libraries
• Using the settings shown below as an example, modify your Log4J configuration file to specify the settings for the Monitis Appender

<appender name="monitisAppender">
       <param name="monitisApiKey" value="2PE0HVI4DHP34JACKCAE37IOD4" />
 
       <param name="monitisSecretKey" value="7OI90FU3C3DA8ENLNJ0JGGOGO0" />
 
       <param name="monitisMonitorName" value="Log_files_monitor" />
 
       <param name="monitisMonitorTag" value="Custom_logger_monitor" />
 
       <param name="monitisSendInterval" value="60000" />
 
       <layout>
 
           <param name="ConversionPattern" value="%d{ISO8601} %-5p [%t]: %m%n" />
 
       </layout>
 
       <filter>
 
           <param name="filterPattern" value="(Error|Fatal|Warn*|Attention)" />
 
           <param name="minAllowedLevel" value="WARN" />
 
       </filter>
 
</appender>

where:

• monitisApiKey is user personal API key that can be obtained from Monitis user account
• monitisSecretKey is user personal secret key that can be obtained from Monitis user account
• monitisMonitorName is user monitor name (any unique name can be chosen)
• monitisMonitorTag is tag value for user monitors
• monitisSendInterval is time interval [ms] between sending monitored info to Monitis
• ConversationPattern is the pattern that will be used by MonitisAppender to format records
• filterPattern is a pattern-string for selection of log records that you want to monitor

This should be composed as a Java RegEx and correspond to Java Pattern.matches requirements.

(default is no pattern – so all records will be sent to Log Monitor)

• minAllowedLevel is the log4j records level (ERROR, WARN, DEBUG, etc.) that you want to monitor (default value is WARN)

Notes:

• the Log4J configuration should be prepared in XML format because Log4J filter supports XML only
• this approach doesn’t affect your application  performance because Log4J appenders work in separate threads asynchronously
• it can take more memory to run your application because an additional custom appender works in the same JVM bounds
• in comparison to other approaches this approach seems much simpler and doesn’t require additional tools. It’s very close to The Cure for Monitoring Java Logs technique, and simplifies it

The sources and more details can be found in the GitHub.