Apache Maintenance Basics Page 2

By Martin Brown (Send Email)
Posted May 13, 2004


Log Monitoring

Contents
Monitoring Apache
Log Monitoring
Log Management
Configuration Management
Security and Passwords
Keeping Apache Up to Date
Other Systems and Extensions
Scheduling Maintenance

Checking logs is the best way to find out what is going on. Apache 2.0 introduced the generation of a separate error log for the Apache process itself. Checking this, often, is the best way to find out if something needs attention, as examining the logs makes it easy to catch a faulty or missing module or a bad process. Consider this sample fragment:

[Sat May 01 10:00:14 2004] [notice] Apache/2.0.44 (Unix) DAV/2  
configured -- resuming
normal operations
[Sat May 01 10:00:14 2004] [info] Server built: Mar  7 2003 14:41:06
[Sat May 01 10:00:14 2004] [debug] prefork.c(1039): AcceptMutex:  
pthread (default:
pthread)
[Mon May 03 02:09:48 2004] [notice] child pid 23464 exit signal  
Segmentation fault (11)
[Mon May 03 02:19:48 2004] [notice] child pid 10932 exit signal  
Segmentation fault (11)
[Mon May 03 02:29:50 2004] [notice] child pid 23470 exit signal  
Segmentation fault (11)
[Mon May 03 02:39:52 2004] [notice] child pid 23471 exit signal  
Segmentation fault (11)
[Mon May 03 02:49:52 2004] [notice] child pid 23465 exit signal  
Segmentation fault (11)
[Sun May 09 13:20:07 2004] [notice] child pid 21539 exit signal Bus  
error (10)

All log entries are marked with a particular class in much the same way as entries in the system log are marked under the various Unix variants. Log levels include 'notice', which is for notification information only; 'info', which relates to running or log information; 'debug', which is output when debugging on a module is enabled; and 'warn', which notifies of a series problem.

Checking Web host logs should also be a regular activity. These highlight problems with missing files, errors in CGI scripts, and users trying to access files and directories that no longer exist. Note, though, that some errors from a site are to be expected, even if everything tests out okay elsewhere.

The important things to look out for are unexpected items, rather than missteps you might repeatedly be making. For example, say you frequently forget to add a 'favicon' to your sites; you would then get many errors with browsers looking for a file which will never exist. But errors in a CGI or other item you would want to know about.

If you are on a Unix system, and using the standard error log format, the following command generates a unique list of errors from a log file:

$ tail -100 www-error_log | cut -d']' -f 4-99 | sed -e "s/,  
referer.*//g"|sort|uniq

pulls out the most recent 100.

$ cat www-error_log | cut -d']' -f 4-99 | sed -e "s/,  
referer.*//g"|sort|uniq

searches the entire file.

To monitor the significance, add '-c' to the uniq command, which will find you a count of the number of each error.



Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.