Настройка ротации логов в Linux: подробное руководство

Введение / Зачем это нужно

Логи приложений и системы в Linux неумолимо растут со временем. Если оставить их без контроля, они могут занять весь доступный диск, привести к сбоям сервисов и усложнить поиск нужных событий. Ротация логов — это стандартный механизм автоматического архивирования, сжатия и удаления устаревших записей. В большинстве дистрибутивов Linux для этого используется утилита logrotate. После настройки вы получите:

• Контроль над использованием дискового пространства.
• Упрощённый анализ thanks структурированным архивам.
• Автоматизацию рутинной задачи без участия администратора.

Этот гайд покажет, как настроить logrotate для ваших приложений на современных системах (Ubuntu, Debian, CentOS, Fedora).

Требования / Подготовка

Перед началом убедитесь, что у вас есть:

1. Доступ к терминалу Linux с правами суперпользователя (sudo).
2. Установленная утилита logrotate (обычно предустановлена). Проверить можно командой:

   logrotate --version
   

3. Знание расположения логов вашего приложения. Например, для веб-сервера Apache это /var/log/apache2/, для Nginx — /var/log/nginx/. Если логи хранятся в нестандартном месте, найдите их через find или проверьте конфигурацию приложения.
4. Базовое понимание текстовых редакторов (nano, vim) для редактирования конфигурационных файлов.

Пошаговая инструкция

Шаг 1: Проверьте установку logrotate

Хотя logrotate обычно идёт в комплекте с системой, в минимальных установках его может не быть. Проверьте версию:

logrotate --version

Если команда не найдена, установите:

• Для Ubuntu/Debian:

  sudo apt update
  sudo apt install logrotate
  

• Для CentOS/Rocky/Fedora:

  sudo dnf install logrotate
  

После установки повторно проверьте версию. Актуальные версии (3.15+) поддерживают все современные опции.

Шаг 2: Создайте конфигурационный файл

Logrotate использует две типы конфигураций:

• Глобальный файл /etc/logrotate.conf — задаёт общие параметры (например, как часто запускаться).
• Файлы в /etc/logrotate.d/ — содержат настройки для конкретных приложений. Это предпочтительный способ, так как он не мешает обновлениям пакета.

Создайте файл для вашего приложения. Например, для кастомного приложения myapp, логи которого лежат в /var/log/myapp/:

sudo nano /etc/logrotate.d/myapp

Вставьте базовую конфигурацию:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 root root
    sharedscripts
    postrotate
        systemctl reload myapp.service > /dev/null 2>&1 || true
    endscript
}

Пояснение параметров:

• /var/log/myapp/*.log — путь к логам (поддерживаются wildcards).
• daily — ротация каждый день. Другие варианты: weekly, monthly, yearly.
• rotate 7 — хранить 7 архивов (после этого самые старые удаляются).
• compress — сжимать архивы с помощью gzip (файлы получат расширение .gz).
• delaycompress — сжимать не сразу, а на следующем цикле (удобно, если приложение ещё пишет в предыдущий файл).
• missingok — не выдавать ошибку, если файл лога отсутствует.
• notifempty — не ротировать пустые файлы.
• create 644 root root — создавать новый файл лога после ротации с указанными правами и владельцем.
• sharedscripts — выполнять postrotate только один раз для всех файлов, а не для каждого.
• postrotate / endscript — команды после ротации. Здесь мы перезагружаем сервис myapp, чтобы он начал писать в новый файл. Если сервис не требует перезагрузки, блок можно удалить.

Сохраните файл (Ctrl+O, Enter, Ctrl+X в nano).

Шаг 3: Настройте параметры ротации под ваши нужды

Отредактируйте конфиг, учитывая особенности:

• Частота ротации: если логи очень активные, используйте hourly (но потребуется дополнительная настройка cron/systemd). Для большинства случаев достаточно daily.
• Хранение: rotate 30 — хранить месяц. Учитывайте доступное место: сжатие уменьшает размер в 5-10 раз.
• Размер вместо времени: если нужно ротировать по размеру, замените daily на:

  size 100M
  

  Это значит ротация при достижении 100 МБ.
• Удаление без сжатия: если сжатие не нужно, уберите compress и delaycompress.
• Логи нескольких каталогов: можно указать несколько путей или использовать wildcards, например:

  /var/log/myapp/*.log /var/log/myapp/audit/*.log {
      ...
  }
  

• Права на новые файлы: параметр create должен соответствовать тому, как приложение ожидает seeing файлы. Обычно 644 для обычных логов, но для защищённых может потребоваться 600.

Важно: Если приложение пишет логи напрямую в /dev/stdout (например, Docker-контейнеры), logrotate может не сработать — в таком случае ротацию нужно настраивать на уровне оркестратора.

Шаг 4: Протестируйте конфигурацию

Не ждите следующего запуска по расписанию — проверьте конфиг сразу:

sudo logrotate -d /etc/logrotate.conf

Флаг -d включает режим сухого запуска (dry-run): logrotate покажет, что сделал бы, но не внесёт изменений.

В выводе ищите:

• reading config file /etc/logrotate.d/myapp — конфиг загружен.
• rotating pattern: /var/log/myapp/*.log — путь распознан.
• old log is removed или log does not need rotating — ожидаемое поведение.
• Ошибки: error: error accessing /var/log/myapp/... — проблема с правами или путём.

Если всё выглядит хорошо, выполните принудительную ротацию для теста (но осторожно — это реально переместит файлы):

sudo logrotate -vf /etc/logrotate.conf

Флаги:

• -v — подробный вывод.
• -f — принудительный запуск, даже если не пора.

После этого проверьте директорию /var/log/myapp/ — должны появиться архивы (например, myapp.log.1.gz) и новый файл myapp.log.

Шаг 5: Проверьте статус и журнал

Logrotate записывает, когда последний раз ротировал каждый файл, в файл статуса (по умолчанию /var/lib/logrotate/status). Посмотрите его:

sudo cat /var/lib/logrotate/status

Вы увидите записи вроде:

/var/log/myapp/myapp.log 2026-2-16-10:30:1

Это подтверждает, что ротация прошла.

Также проверьте логи cron или systemd, чтобы убедиться, что задача запускается по расписанию:

• Для систем с cron (Ubuntu/Debian до recent versions):

  grep logrotate /var/log/cron.log
  

  Или посмотрите файлы в /etc/cron.daily/ — там должен быть скрипт logrotate.
• Для систем с systemd (CentOS 8+, Fedora, Ubuntu 22.04+):

  systemctl status logrotate.timer
  

  Таймер обычно настроен на ежедневный запуск. Если нужно изменить расписание, редактируйте юнит logrotate.timer (через systemctl edit logrotate.timer).

Шаг 6: (Опционально) Настройте запуск через systemd timer

В современных дистрибутивах logrotate часто запускается через systemd timer, а не cron. Это даёт более гибкое расписание.

1. Проверьте, активен ли таймер:

   systemctl is-enabled logrotate.timer
   

   
   Должно вернуть enabled.
2. Если вы хотите изменить время запуска (например, на 2:30 вместо 6:25), создайте оверрайд:

   sudo systemctl edit logrotate.timer
   

   
   В открывшемся редакторе добавьте:

   [Timer]
   OnCalendar=daily
   Persistent=true
   RandomizedDelaySec=0
   

   
   Или укажите конкретное время:

   OnCalendar=*-*-* 02:30:00
   

   
   Сохраните и перезагрузите демон:

   sudo systemctl daemon-reload
   sudo systemctl restart logrotate.timer
   

3. Для ежечасной ротации создайте отдельный таймер или измените конфиг в /etc/cron.hourly/ (если система использует cron). Но помните: частая ротация может нагружать систему, если логов очень много.

Проверка результата

После настройки убедитесь, что ротация работает стабильно:

1. Подождите следующий цикл (если тестировали через -f, пропустите этот шаг) или запустите вручную: sudo logrotate -vf /etc/logrotate.conf.
2. Проверьте наличие архивов: в директории логов должны быть файлы с суффиксами .1, .1.gz (или .2 и т.д., в зависимости от rotate).
3. Убедитесь, что новые логи пишутся:

   tail -f /var/log/myapp/myapp.log
   

   Новые записи должны появляться.
4. Контролируйте место на диске:

   du -sh /var/log/myapp/
   

   Общий размер не должен бесконечно расти.
5. Проверьте, что сервис не падает: если в postrotate была перезагрузка, убедитесь, что приложение работает:

   systemctl status myapp.service
   

Если все пункты выполнены, ротация настроена корректно.

Возможные проблемы

Ошибка доступа к файлам логов

Симптом: error: error opening /var/log/myapp/*.log: Permission denied. Решение: Logrotate запускается от root, но если логи принадлежат другому пользователю, убедитесь, что у root есть права на чтение. Проверьте владельца:

ls -la /var/log/myapp/

Если нужно, измените права или добавьте root в группу владельца.

Логи не ротируются

Симптом: После logrotate -vf ничего не происходит, файлы не перемещаются. Причины:

• Файл не соответствует маске (например, myapp.log.1 вместо myapp.log). Уточните путь в конфиге.
• Файл пустой, а стоит notifempty. Уберите эту опцию или создайте тестовую запись.
• Ротация уже недавно была (сравните дату в /var/lib/logrotate/status). Принудительный запуск с -f должен помочь.

Сжатие не работает

Симптом: Архивы создаются, но без .gz. Решение: Убедитесь, что установлен gzip (обычно есть). Проверьте:

which gzip

Если нет, установите: sudo apt install gzip (Debian/Ubuntu) или sudo dnf install gzip (RHEL/Fedora).

Сервис падает после ротации

Симптом: После ротации приложение перестаёт писать логи или завершается. Причина: Команда в postrotate (например, systemctl reload) может завершаться с ошибкой, если сервис не существует или требует полной перезагрузки. Решение:

• Проверьте, существует ли сервис: systemctl list-units | grep myapp.
• Используйте reload только если сервис поддерживает SIGHUP. Иначе используйте restart.
• Добавьте || true в команду, чтобы игнорировать ошибки (как в примере выше).

Ротация происходит не по расписанию

Симптом: Файлы статуса не обновляются, архивов нет. Решение:

• Для cron: убедитесь, что пакет cron запущен (systemctl status cron), и что скрипт /etc/cron.daily/logrotate существует и исполняем.
• Для systemd: проверьте таймер logrotate.timer и его состояние (systemctl list-timers | grep logrotate). Возможно, таймер отключён — включите: sudo systemctl enable --now logrotate.timer.
• Если вы только что настроили конфиг, убедитесь, что он синтаксически корректен (проверьте через logrotate -d).

Диск всё равно заполняется

Симптом: Даже после ротации место на диске не освобождается. Причины:

• rotate установлен в слишком большое значение (например, rotate 365). Уменьшите.
• Сжатие отключено (compress нет). Включите.
• Логи пишутся в другие директории, не охваченные конфигом. Найдите все логи приложения: find / -name "*.log" -path "*myapp*" 2>/dev/null.
• Сам процесс ротации создаёт временные файлы. Убедитесь, что на диске достаточно места для сжатия (временно нужно место под оригинал + архив).

Если проблема остаётся, добавьте мониторинг диска (например, через cron и df -h) и анализируйте, какие файлы растут.