DevOps Zone is brought to you in partnership with:

Trevor Parsons is CEO and Co-founder of Logentries, 'the log management and intelligence platform'. Trevor has over 10 years experience in enterprise software and in particular has specialised in developing enterprise monitoring and performance tools for enterprise systems. He is also a research fellow at the Performance Engineering Lab Research Group and was formerly a Scientist at the IBM Center for Advanced Studies. Trevor holds a PhD from University College Dublin, Ireland. Trevor is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

Collecting and Analyzing Logs from Your Java Application

06.13.2014
| 5214 views |
  • submit to reddit

le_java is one of several libraries that allow you to send log data directly to your Logentries account from your application.  le_java supports both the log4j and logback logging libraries in java, and can be configured to work with either - in just a few steps!  (Check out: github.com/logentries/le_java/blob/master/README.md for our complete tutorial.) Using Logentries to collect log data from java applications

Once you have your application sending logs to your Logentries account, you can decide how you want to use them. Anywhere in your code that you have an important event or critical data, you can use one of the following to send a log; any valid string can be sent as an argument which will be appended to a default pattern as set in your .xml configuration file.

Assumes an instance of the logging object ‘log’ has been created, see the above linked tutorial.

log.debug("contents");
log.info("contents=” + someVariable);
log.warn("contents=" + someVariable + “ other=“ + someOtherVariable);
log.error("any valid string can go here”);

If you use logback or log4j already, the above should look familiar. The logentries le_java library allows you to use the existing syntax you have for logs, but they are now also forwarded to the Logentries log associated with the token you will have placed in the .xml configuration for logback or log4j, samples of which are included in le_java.

With the le_java library, you can easily put any log data you want into the logging methods argument as any valid string. You can concatenate one or more variables’ names and values which can subsequently be used for searches, tags, and alerts in the Logentries web app. You choose what data and events in your application are important to you and it will be logged in the format you prefer and sent directly to your Logentries account. Once there, it is always available for analysis in future, and you can easily build real-time alerting on top of these for immediate notification based on events or activities.

You can set the <pattern> field in the .xml configuration to include various information. By default it includes the thread, logger (Logentries) and the string argument sent to the logging method. You also have an option to include the class sending the log (%class{0}) the method (%method) and the line (%L). These, and the contents of the argument string, will become the log output and can be used to search for particular logs and in conjunction with the real-time tags and alerts system, ensuring that important incidents in your application are noted appropriately and their origin in the code.

Using the le_java library (github.com/logentries/le_java) you can send logs directly from your java application to your Logentries account. Once you’ve collected these logs, Logentries enables easy searching, tagging and alerting, visualizations and analytics that may otherwise be missed if you did not have this access. Tags and alerting with Logentries

Logentries also supports Ruby, PHP, Python, JavaScript, .Net, Android and others — check out github.com/logentries for our full list of public repos.

Visit us at logentries.com/doc/ to see all of the cool things you can do with your log data.

Published at DZone with permission of Trevor Parsons, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)