Working with Apache Error Log Files

Apache, an open source web server that dates back to the mid-1990s, is one of the oldest web servers still in widespread use today. It remains one of the most popular web server platforms out there (even though NGINX has been slowly eroding its market share for a while).

This means that there is a good chance that you’ll find yourself at some point working with Apache logs, if you’re not already. Below, I explain how logging in Apache works, where to find logs, what to look for in them and which tools can help you work with them.

For this post, I’ll focus on Apache error logs. Some of these tips apply to Apache error logs as well.

Where is the error log?

Depending on your Linux distribution, log files may be available in different folders. One point that influences the location of the logs is the type of installation done from Apache. If you did a default installation, follow the log storage location(s).

RHEL / Red Hat / CentOS / Fedora
/var/log/httpd/error_log

Debian / Ubuntu
/var/log/apache2/error.log

FreeBSD
/var/log/httpd-error.log

To find the exact Apache error log file location(s), you can use the grep command:

$ grep ErrorLog /usr/local/etc/apache22/httpd.conf
$ grep ErrorLog /etc/apache2/apache2.conf
$ grep ErrorLog /etc/httpd/conf/httpd.conf

Sample output:

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a
ErrorLog “/var/log/httpd-error.log”

In order to succeed in log reading, you need to know the structure of the log, and where to find it. In the case of Apache running on Linux servers, there are default paths.

The default format of the Apache error log is defined by the ErrorLogFormat directive. It takes this form:

ErrorLogFormat “[%t] [%l] [client %a] %M”
%t is time relative to the server
%l is the level of the message (error, notice, fatal, etc.)
%a is the client IP making the request (if it exists)
%M is the actual error message

An example:

[Sun Jul 09 03:25:02 2017] [notice] Apache/2.2.32 (Unix) DAV/2 configured -- resuming normal operations
[Sun Jul 09 04:06:13 2017] [error] [client 1.2.3.4] File does not exist: /var/www/html/robots.txt
[Mon Jul 10 20:24:52 2017] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8484 (localhost) failed

Why use tools to monitor Apache logs?

When you see log lines, you’ll soon notice that they are not easy or quick to read. And it isn’t easy to identify and separate information from a log, especially a high volume of logs that needs to be analyzed constantly, or information that needs to be abstracted dynamically and urgently.

The reading of an Apache log can be severely lacking—or it can be very dynamic, elegant and easy. Passably, you need to access the server, find the path of the log files (with a tail -f provided), and continuously look at the screen, trying to keep track of real-time dynamic information continuously coming to the server.

The easiest and most dynamic way to simplify the process is to use an application that interprets the data and displays it in a dashboard that shows what you need to know. You can, as an example, view a history of the logs and see if there is a default in a given error. When data is transformed into information, it can then be turned into business strategies and direct investments.

Viewing Apache logs

When you have a tool for displaying the data stored in a log, you can quickly find the answers you need. To monitor Apache logs, the easy-to-use Sumo Logic Apache App service is a great choice. You can quickly install the application and configure it to receive the data from your server, and display needed information.

The data that can be monitored are:

1. Bytes Delivered
2. HTTP Errors
3. Page Hits
4. Response Time
5. Web Server

This data allows you to work safely, and analyze all traffic your application receives.

Conclusion

Apache error logs may seem straightforward. (After all, the Apache platform has existed for more than two decades.) To ensure uptime SLA you need more than just greping log files or other ad hoc approach. You should develop a systematic way to centralize and analyze Apache error logs. That should involve tracking and analyzing HTTP error codes, identifying outlier IP addresses and listing pages with slow response time and various other metrics which can improve the uptime and MTTR. Either you can identify those metrics by yourself or you can use Sumo Logic’s Apache application to track and monitor those metrics.