Home/Blog/Log4j/Log4j: Defining AppTags for Faster Error Detecting
Log4j: Defining AppTags for Faster Error Detecting
Make your searches for anomalies in your log4j logs more effective with AppTags
There are many tools and methods out there speeding up your search for errors, but have you tried adding AppTags to your logs? In this series of posts I am covering some of the ways you can benefit from XpoLog V6’s new features and enhancements. I will concentrate mainly on how to get the most valuable information from your log4j event logs. Once your log4j logs have been transferred to and properly defined in XpoLog Center, you can troubleshoot your java application by running Analytic Search on your log4j data, measure your application performance, create your own Apps or use XpoLog’s Apps for better monitoring, and create dashboards, charts, slide-shows, and make use of other visualization gadgets for maximum analysis. This post will show you how to add AppTags to your logs to perform more enhanced searches. To read all our posts together, see our online hands-on-guide. If you want to test out the software as you go along, you can download it for free. Adding AppTags to your logs in XpoLog can make any search, simple or complex, extremely powerful; as you will see later on.
Adding AppTags to log4j logs
If you look at one of my previous posts, Log collection and Appender configuration, you will notice that when adding a log to XpoLog, you are given the option of tagging the log to a number of applications, and you can also create new AppTags. Once your data has been transferred into XpoLog and been properly defined with regards to pattern and AppTags, start searching. You can do a Simple Search or a Complex Search. A good and detailed pattern together with well thought-through AppTags for a log will make either search that much more effective. To show you the power of the AppTags, I will begin by drawing a sketch: Imagine you have 3 servers, Server1, Server2, and Server3, and plenty of log4j files in each server. There are times you want to search in all of the files in all of the servers, and times you want to search files in one or two of the servers. Inside XpoLog, create a log for each server, call them log4j_server1, log4j_server2, and log4j_server3. Then create an AppTag for all three logs and call it Log4J. Create an AppTag for the first log called “Georgia” and an AppTag for the second and third logs called “Atlanta”. Imagine that Georgia and Atlanta are the locations of your servers.
Simple Search examples
Now let’s do a simple search where we utilize the AppTags in the sketch. Say we want to look for a word that appears in the log4j files in Server1. Inside XpoLog Center, go to Search, in the search field, type: * in log.log4j server1 where * = anything. The result will show you what anomalies appear in any file in Server1. Now look for the word “ERROR” in all the files on all 3 servers. Inside XpoLog Center, go to Search, in the search field, type: error in log.log4j server* where * = anything. Hence, in this example, the * refers to the numbers 1, 2, and 3. The result will show you where the word “ERROR” appears in any file in any of the 3 servers. Now look for the word “remote” in any file on any server that is situated in Atlanta. In our example this means Server2 and Server3. Inside XpoLog Center, go to Search, in the search field, type: remote IN apptag Atlanta The result will show you where the word “remote” appears in any file in any server that has been tagged with “Atlanta”. The reason this AppTag is so useful is that should you add more servers in Atlanta, or Georgia, and you want to just continue looking for texts or abnormalities in these servers, the moment you give the new server the AppTag “Atlanta” or “Georgia”, XpoLog will continue its search and automatically include searching through any files placed on the new servers. The same goes for removing a server. Once a server is removed, XpoLog will automatically continue its search through all files on all servers that are still there. No further configuration is necessary. Now let’s look at an example which takes the pattern into consideration. In the previous post we saw how editing the pattern adds columns to the Log records analysis result field. In the Pattern Editor, we added the priority. Let’s conduct a search where we look for all log4j logs where the priority is ERROR. Inside XpoLog Center, go to Search, in the search field, type: priority=error in log.log4j server* * = anything. Hence, in this example we are searching through all the files on all the servers.
Complex Search example
XpoLog automatically detects errors in the search results and presents these as suggestions (tagged to low/medium/high severities) next to the search results. This technique is known as “Integrated Layers” and it boosts troubleshooting and exposes issues in the logs you may never have thought of and this in turn helps you find the source of various problems faster. Similar to the Simple Search, running a Complex Search query results in a summary table, presented in a tabular format, and you can also create dashboards and other visualization gadgets for an easier, more natural view; something I will cover in my upcoming posts. XpoLog performs advanced complex operations and reporting on any log events according to the criteria you ask for. As an example, let’s look for the word “ERROR” or “Exception” in all log4j files on all servers, but also ask XpoLog to count how many errors (or exceptions) were found in each class. Inside XpoLog Center, go to Search, in the search field, type: error or exception in log.log4j server* | count | group by class The result will show you a table with a list of all classes where errors were found, and how many errors in each. Complex Search provides the option to aggregate log data and to generate advanced statistics, trends, business intelligence, and transactions analysis on the log data. I will speak more about this in my next post. Stay tuned or check out our documentation.