Log Rotation and Archiving

Server logs are essential for debugging and monitoring, but they can grow very large over time. If left unchecked, they can quickly fill up your disk space, leading to server instability or even crashes.

This is where log rotation comes in. It's a critical process for managing log file sizes efficiently.

Linux systems use a utility called logrotate to automate the management of log files. It's designed to:

• Rotate logs (rename old ones)
• Compress old logs to save space
• Remove ancient log files
• Run custom scripts after rotation

Most Linux distributions have logrotate pre-installed and configured to run daily via a cron job.

logrotate reads its configuration from specific files. There are two main places:

• /etc/logrotate.conf: The main configuration file, often containing global settings and default values.
• /etc/logrotate.d/: A directory where individual applications and services place their own specific log rotation rules. Each file in this directory is treated as a separate configuration.

This modular approach makes it easy to manage rules for different services.

One of the first things to define is how often logs should be rotated. logrotate offers several directives for this:

• daily: Rotate logs every day.
• weekly: Rotate logs once a week.
• monthly: Rotate logs once a month.
• yearly: Rotate logs once a year.

Choose a frequency that balances log detail retention with disk space usage.

The rotate directive tells logrotate how many old log files to keep before deleting the oldest ones. For example, rotate 4 means it will keep the current log file, plus four rotated (archived) versions.

Once the limit is reached, the oldest rotated log is removed when a new rotation occurs.

To save even more disk space, logrotate can compress old log files. The compress directive does exactly this, typically using gzip.

When this is enabled, your rotated logs will appear as .gz files (e.g., myapp.log.1.gz). This is highly recommended for most server logs.

Sometimes, logs can grow very quickly, and waiting for a daily or weekly rotation isn't enough. The size directive allows you to rotate logs if they exceed a certain file size, regardless of the time frequency.

• size 100k: Rotate if log file is larger than 100 kilobytes.
• size 10M: Rotate if log file is larger than 10 megabytes.
• size 1G: Rotate if log file is larger than 1 gigabyte.

If both a time frequency (e.g., daily) and size are specified, rotation happens if either condition is met.

Here's a simple example of a configuration file you might find in /etc/logrotate.d/ for a hypothetical application's log file:

This config will rotate the log daily, keep 7 old copies, and compress them.

While logrotate usually runs automatically via cron, you can test or force a rotation manually. The main command is logrotate /etc/logrotate.conf.

To force a rotation (useful for testing your configurations), use the -f flag:

• logrotate -f /etc/logrotate.d/my_app: Forces rotation for a specific config file.
• logrotate -f /etc/logrotate.conf: Forces rotation for all configured logs.

Use the -d (debug) flag to see what it would do without actually rotating anything.

Consider the following logrotate configuration for /var/log/webserver/error.log:

If this configuration has been running for several weeks, how many *compressed* historical log files would you expect to find at any given time?

In this lesson, we explored how to manage server logs effectively using logrotate. We learned that:

• Log rotation prevents disk exhaustion.
• logrotate uses configuration files in /etc/logrotate.conf and /etc/logrotate.d/.
• Key directives include daily/weekly/monthly for frequency, rotate for retention, compress for saving space, and size for conditional rotation.

Proper log management is a cornerstone of stable server operations!