Why Rotation of log files is important.
The idea behind log rotation is simple: make a back up of the current log file, continue logging into a new or cleared log file, and discard log files that are older than a certain date. Your web server probably already rotates its own log files. For Apache, they are probably located in/etc/httpd/logs and they are probably rotated weekly. These logs store everything Apache does. Simple webserver stats and traffic analysis tools make use of these log files to show who visits a site when and what pages are viewed. While it is possible to configure your Rails application to log to your Apache log files, I do not think it is a good practice. It’s much better to give each Rails application its own log file—it will be easier to find important Rails errors, it will keep your Apache logs cleaner and Rails is set up to keep its own logs by default. Fortunately, on a Linux server the built-in logrotate program will make the process super-easy. After the jump, I’ll walk you through the steps to get it set up. Configuring logrotatelogrotate gets its configuration information from the file /etc/logrotate.conf. If you can’t find it, you can type locate logrotate.conf from the command line to see where it lives. Open up that file in a text editor (nano /etc/logrotate.conf will work) and append the following lines at the end:
1 2 3 4 5 6 7 8 9 10 11
Here’s what each line does:
Use the full path to the log directory of your Rails application (symbolic links are acceptable too). “*.log” will rotate any file in the log directory with .log at the end. If you only want to rotate certain log files you can be more specific.
Rotates the log files every day. You could specify weekly or monthly instead.
Don’t issue an error message if log files are missing.
The maximum number of log files to keep. Once you have more than this number, the oldest file will be deleted. I set it to keep seven days worth but feel free to change this number.
Compress old versions of log files to save space (uses gzip by default).
Delays the compression until the next log rotation. It’s a minor point and probably not strictly necessary, but it makes sure that the log file is truly no longer active before compressing it.
If the log file is empty, there’s no need to rotate it. You can remove this option if you want to rotate even blank log files; just keep in mind that you may erase a log file that has lots of information to make room for your blank log file.
Makes a backup copy of the current log and then clears the log file for continued writing. The alternative is to use create which will perform the rotation by renaming the current file and then creating a new log file with the same name as the old file. I strongly recommend that you use copytruncate unless you know that you need create. The reason why is that Rails, FastCGI, Mongrel, etc. may still keep pointing to the old log file even though its name has changed and they may require restarting to locate the new log file. copytruncate avoids this by keeping the same file as the active file.
If you have more than one Rails application, you can repeat this code to rotate them all one-after-another. There other options you can specify, man logrotate will show you them all. I haven’t used them but the options to mail log files on creation or deletion look interesting. It is also possible to have rotate the logs once they get to a certain size instead of at a certain time.
To use the log rotation you just configured, you have two choices.
- Wait for the next day (or whatever time period you specified). If you configured it correctly, rotation should occur automatically and without further commands.
- Run it immediately by typing /usr/sbin/logrotate -f /etc/logrotate.conf on the command line. (The -f is for “force it to run now.)
That’s all there is to it! Now your log files won’t fill up to an unmanagable size yet you’ll still be able to go back and track any recent errors.