As systems administrators, application logs are often the key to our success, but also our biggest hassle. They provide clues to what’s going on when things go awry, and in those situations more detail is generally better. But when you don’t actually know something is wrong, and just want to get a sense for whether things are normal, more detail can create so much noise that it’s all but impossible to glean any useful information.

In those situations, you’d rather just have statistical information about what’s in your logs. In this article, I present a simple and easy solution to turn your logs into useful graphs, in real time. If you ever need to measure the volume of your logs, or perhaps graph the frequency of certain log events, then read on.

The tools

The solution I present uses four key tools:

• Log4J (though plain log files would fit as well)
• Logstash
• StatsD
• Monitis

With so many moving parts, you might be tempted to think this could be an overcomplicated solution. But in fact — as in the long tradition of Unix command line tools — it is a composition of simple tools each doing one job very well. As with files piped from one Unix command to another, these four components act as a pipeline for log events, with each piece adding value to the stream along the way.

Log4J

All of the log events in this article start inside of Log4J. If you run Java applications, then this provides an easy way to hook into your logs, to peel off an event stream that you want to see graphed in Monitis. But, Log4J could easily be replaced in this solution with plain log files, syslog, or any number of other logging frameworks.

The key modification that we make to Log4J is to add a SocketAppender that sends a copy of selected Loggers to our logstash server.

Logstash

The role of logstash in the pipeline is twofold. First, it listens for connections from Java application servers, accepting streams of logs when they connect. Second, it filters, modifies, and routes those streams to the appropriate outputs. In this case, we’ll be handling all of the incoming streams by notifying StatsD each time a log event is received, without actually sending the content of each event.

StatsD

Logstash will be receiving log events very frequently, but Monitis only wants to receive updates at most once per minute. To resolve this mismatch, StatsD acts as our log stream bean counter, allowing logstash to send increment messages each time an event is received. StatsD records these in counters for each type of log message, and then sends the counts on to Monitis every 60 seconds.

Monitis

Finally, we get to the end of the pipeline, and Monitis receives the count messages. These are added to the appropriate custom monitors, which are automatically created if they don’t already exist. Once the data is in Monitis, it can be graphed in the Web UI, or used to send alerts when a rate of log events is outside of a user-specified threshold.

The gory details

Now that you’ve seen the overview, let’s take a look at the configuration details that make it happen. Don’t worry, since each component in the pipeline is doing a simple job, there’s really not much to it.

Install and configure the software

Let’s look at installation details for the tools in each step in the pipeline. I’m assuming that you already have Java applications using Log4J. If not, modifying the pipeline to read from log files, receive from syslog, or other options is pretty straightforward, but outside the scope of this article. For that, refer to the logstash documentation on how to set up other kinds of logstash inputs.