ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Log Management
|
Contents Monitoring Apache Log Monitoring Log Management Configuration Management Security and Passwords Keeping Apache Up to Date Other Systems and Extensions Scheduling Maintenance |
For obvious reasons, it’s a good idea to keep logs for a while to track and trace problems. You’ll also probably want to keep access logs for a long time to perform the necessary analysis. Error logs can be disposed of every three months — once you’ve gone through the steps above to check out any errors or potential problems.
The most effective way of doing this in the standard Apache release (without any clever configuration tricks) is to:
- Shut down Apache
- Rename the error and access logs
- Restart Apache
This obviously shuts down Apache for a period, which you may not want to do if the server is busy. To get around this, use the piped log system, which outputs log information through an external command that can automatically rotate and archive the information. Apache, in fact, provides the rotatelogs application as part of the standard kit to do this. Rotatelogs accepts the name of the log, and the interval for rotation (in seconds).
To enable rotatelogs, change the configuration file to use the pipe system for each log file:
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common |
The number 86400 is the number of seconds in a day. On a busy site, it is preferable to decrease that value so the rotation is performed every six hours, or even every hour. On less busy sites setting it for every week or month would work.
We recommend writing all logs into a custom MySQL database. This makes it easier to get out information from both error and access logs. The fields in the SQL table match those in the output, and an extra field records the name of the Web site.
Configuration Management
Many Web servers rarely have their configuration files modified and updated; others regularly add new configurations, virtual hosts, and other elements. Two ways to ensure the configuration is up to date and working are 1) checking the configuration and 2) tracking configuration changes.
Checking the configuration periodically highlights any problems (including any disparity between the currently running Apache and the current configuration file). Sometimes, it will even highlight changes made to the Apache configuration of which you
may not have been aware.
Checking the configuration can be handled with the apachectl command with the configtest argument:
$ apachectl configtest Processing config directory: /etc/httpd/sites/*.conf Processing config file: /etc/httpd/sites/0000_192.168.1.24_80_atuin.mcslp.pri.conf Processing config file: /etc/httpd/sites/ 0001_192.168.1.24_80_cheffy.devel.atuin.mcslp.pri_copy.conf Processing config file: /etc/httpd/sites/0001_any_80_cheffy.devel.atuin.mcslp.pri.conf Processing config file: /etc/httpd/sites/0002_any_80_webmail.mcslp.pri.conf Processing config file: /etc/httpd/sites/virtual_host_global.conf [Wed May 12 11:07:11 2004] [warn] module mod_WebObjects.c is already added, skipping Syntax OK |
The ‘Syntax OK‘ line at the end is the key piece.
Configuration management is about keeping a history of the changes you’ve made to your configuration file. The easiest way to do this is to use RCS or CVS to check in any configuration changes made. They not only track the changes and differences between versions, but also enable you to record a log of the changes made and recover previous versions.
If you’re worried you will forget to log the changes, you can run a script each night to automatically check the latest version of the script, along with a suitable description to identify the automatic changes:
cd /export/http/apache2/conf cvs commit -m "Nightly auto-commit" |
