Linux

Как настроить logrotate на Ubuntu и проверить ротацию логов

Настраиваем ротацию файлового журнала, проверяем расписание и испытываем сжатие на временном логе.

Файловый журнал сжимается и отправляется в архив

logrotate периодически переименовывает, сжимает и удаляет старые файловые журналы. Для приложения на Ubuntu обычно достаточно одного правила в /etc/logrotate.d/ и штатного расписания. Перед настройкой выясните, где процесс пишет логи и умеет ли открывать новый файл после ротации.

Найти источник журнала

sudo journalctl -u myapp.service -n 40 --no-pager
sudo du -ah /var/log/myapp | sort -h | tail -15
systemctl list-timers --all logrotate.timer

Если myapp пишет в stdout/stderr службы systemd и записи видны через journalctl, за их хранение обычно отвечает journald. Измерьте его объём через journalctl --disk-usage. Постоянное ограничение дискового хранения задаётся в journald.conf или drop-in, например через SystemMaxUse. Файлы .journal управляются самим journald. Правило ниже предназначено для текстовых логов в каталоге приложения.

Проверьте наличие штатного правила пакета, особенно для Nginx, PostgreSQL и других установленных служб. Один лог должен обрабатываться одним правилом. Если нужно понять, почему место всё ещё занято после очистки, используйте проверку открытых удалённых файлов.

Создать правило для файлового лога

Пример рассчитан на /var/log/myapp/app.log. Служба пишет от имени пользователя и группы myapp, а команда systemctl reload myapp.service действительно переоткрывает журналы. Сначала проверьте это по документации приложения. Способ обработки reload задаёт сама служба.

/var/log/myapp/app.log {
    daily
    maxsize 50M
    rotate 7
    missingok
    notifempty
    compress
    delaycompress
    su myapp myapp
    create 0640 myapp myapp
    postrotate
        /usr/bin/systemctl reload myapp.service
    endscript
}

Сохраните правило в /etc/logrotate.d/myapp от имени root. Подставьте имена существующих пользователя и группы. Каталог и исходный файл должны позволять myapp выполнять ротацию и запись. su задаёт пользователя для операций над файлами. Скрипт postrotate выполняется с правами, с которыми запущен сам logrotate, поэтому в правило нельзя подставлять команды или пути из пользовательского ввода.

daily задаёт дневной интервал. maxsize позволяет сделать ротацию раньше, если очередной запуск увидит файл больше 50 МБ. При запуске раз в сутки размер может заметно превысить 50 МБ между проверками. rotate 7 означает семь архивов, а реальный срок хранения зависит от частоты ротации. delaycompress откладывает сжатие свежего архива до следующего цикла. Процессу всё равно нужно вовремя переоткрыть файл.

Если переоткрытие невозможно, logrotate поддерживает copytruncate. Этот режим копирует данные и обнуляет существующий файл. Между копированием и обнулением часть строк может потеряться. Для важных логов настройте переоткрытие или вывод в journald.

Проверить настройки и отработать ротацию

Сначала запустите проверку без записи. Общая конфигурация позволяет увидеть конфликт с уже установленным правилом.

sudo logrotate --debug /etc/logrotate.conf
sudo systemctl status logrotate.timer --no-pager
sudo journalctl -u logrotate.service -n 40 --no-pager

Если дистрибутив запускает logrotate через cron, проверьте штатное задание и его журнал. Второе расписание может привести к конкуренции за файл состояния. Подробнее о запуске задач — в руководстве по cron.

Проверить сжатие на временном журнале

Принудительную ротацию удобно проверить на временном журнале с собственным файлом состояния. Этот пример не требует root и не затрагивает /var/log.

demo=$(mktemp -d)
printf 'first request\n' > "$demo/app.log"
cat > "$demo/logrotate.conf" <<EOF
$demo/app.log {
    daily
    rotate 2
    compress
    create 0640
}
EOF
logrotate --debug --state "$demo/state" "$demo/logrotate.conf"
logrotate --force --state "$demo/state" "$demo/logrotate.conf"
ls -l "$demo/app.log" "$demo/app.log.1.gz"
gzip -cd "$demo/app.log.1.gz"
rm -- "$demo/app.log" "$demo/app.log.1.gz" "$demo/state" "$demo/logrotate.conf"
rmdir -- "$demo"

Ожидаемый результат — новый пустой app.log и архив со строкой first request. --force для рабочего конфига запускает реальную ротацию, поэтому применяйте его только к выбранному файлу с учётом hook. После штатного цикла выполните один безопасный запрос к приложению и проверьте, что новая строка попала в новый app.log. Если запись идёт в .1, проверьте переоткрытие и файловые дескрипторы процесса.

На стенде Ubuntu 24.04 мы выполнили пример без root. Logrotate создал новый файл и сжатый архив, из которого удалось прочитать исходную строку.

Первоисточники

Нашли неточность?

Сообщите адрес статьи и фрагмент через контакты редакции.