Настройка Log Rotation (logrotate) для управления размером логов

Мы не раз видели /var/log/nginx/access.log на 47 гигабайт на сервере с 50 GB диском — классика. Наши инженеры знают: логи пишутся месяцами без ротации, пока диск не заполняется, и сервис падает с No space left on device. Или хуже — приложение продолжает работать, но молча перестаёт писать логи, и никто этого не замечает до инцидента. Ручная чистка логов через rm — временное решение, которое неминуемо возвращает проблему. В среднем на каждом сервере мы освобождаем до 30 ГБ дискового пространства, предотвращая простои стоимостью в тысячи долларов в час. За 5 лет работы мы настроили ротацию более чем на 200 серверах — автоматическая ротация с logrotate единственный надёжный способ держать логи под контролем.

Как работает logrotate

Согласно man-странице logrotate, утилита предназначена для упрощения администрирования систем, генерирующих большое количество лог-файлов. logrotate запускается через cron или systemd timer (/etc/cron.daily/logrotate). Читает конфиги из /etc/logrotate.conf и /etc/logrotate.d/. Для каждого лог-файла проверяет условия ротации и выполняет действие: переименовывает, сжимает, отправляет сигнал процессу.

Пример конфига для Nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

delaycompress — сжимает не только что ротированный файл, а предыдущий. Нужно, если процесс держит файловый дескриптор открытым после ротации и дописывает в него ещё какое-то время. sharedscripts — postrotate выполняется один раз для всех файлов маски, не для каждого.

Сигнал USR1 заставляет Nginx переоткрыть файлы логов. Без этого Nginx продолжит писать в переименованный файл через старый дескриптор, а новый access.log останется пустым.

Что входит в настройку logrotate

При заказе услуги мы:

• Анализируем текущую конфигурацию логирования (куда пишут приложения, какие файлы, права доступа).
• Проектируем политику ротации: частота, число архивов, сжатие, обработка postrotate.
• Создаём отдельные конфигурационные файлы для каждого сервиса (Nginx, PostgreSQL, custom-приложения).
• Настраиваем автоматический запуск (cron/systemd timer) и проверяем корректность через logrotate -d.
• Тестируем ротацию в тестовом окружении, а затем применяем на продакшене.
• Передаём документацию по созданным конфигам и инструкцию по мониторингу.

Как настроить logrotate для нескольких приложений?

Для каждого приложения — отдельный файл в /etc/logrotate.d/. Общие параметры выносятся в /etc/logrotate.conf. Мы рекомендуем группировать логи по типу: для веб-серверов (Nginx, Apache) — daily с rotate 14, для более редких логов — weekly с rotate 8. Обязательно добавляйте compress — сжатие уменьшает объём в 4-6 раз по сравнению с несжатыми логами.

Экономия на дисковом пространстве достигает 70%, что при стоимости хранения $90–130 за ТБ в месяц даёт существенную экономию.

Особенности для разных приложений

Journald — отдельная история: journalctl --vacuum-size=2G или параметры в /etc/systemd/journald.conf (SystemMaxUse=2G, MaxRetentionSec=1month). logrotate к бинарному журналу не применяется.

PostgreSQL пишет логи через собственный механизм (log_rotation_age, log_rotation_size в postgresql.conf). logrotate нужен только если включён logging_collector = on с записью в файлы.

Docker — у контейнеров собственная политика логирования (--log-opt max-size=100m --log-opt max-file=5 или в daemon.json). logrotate контейнерные логи не трогает.

Для custom-приложений, которые пишут в /var/log/app/:

/var/log/app/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate } 

copytruncate — копирует файл, затем обрезает оригинал до нуля. Используется, если приложение не умеет переоткрывать файл по сигналу. Минус: между копией и очисткой несколько строк могут потеряться.

Типичные проблемы logrotate

Конфиг написан, но logrotate -d показывает error: skipping "/var/log/app" -- parent directory has insecure permissions. logrotate по умолчанию отказывается работать с директориями, на которые у других пользователей есть write. Фиксируется через su app app в конфиге ротации. Ещё одна причина — файл лога не создаётся (опция missingok это предусматривает) или не выполняется cron. Регулярно проверяйте статус: cat /var/lib/logrotate/status.

Как тестировать конфигурацию logrotate?

# Проверить синтаксис и показать что будет делать — без выполнения
logrotate -d /etc/logrotate.d/nginx

# Принудительная ротация (игнорирует расписание)
logrotate -f /etc/logrotate.d/nginx

# Посмотреть статус последних ротаций
cat /var/lib/logrotate/status

Процесс работы

1. Аналитика: сбор текущих конфигураций, оценка объёмов логов, выявление проблемных мест.
2. Проектирование: выбор политики rotation, размера архивов, сжатия, расписания.
3. Реализация: написание конфигов для logrotate, настройка postrotate/copytruncate.
4. Тестирование: запуск в dry-run режиме, проверка на staging-окружении.
5. Деплой: применение на продакшене, мониторинг в течение недели, корректировка при необходимости.

Сроки ориентировочно

Сроки настройки: от 2 до 4 часов для одного сервера. Для нескольких серверов или сложных конфигураций (например, с кастомными приложениями) — от 4 до 8 часов. Стоимость рассчитывается индивидуально после оценки конфигурации.

Если вы столкнулись с переполнением диска или просто хотите автоматизировать ротацию — свяжитесь с нами для оценки конфигурации. Получите консультацию по ротации логов уже сегодня.