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

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

Логирование — краеугольный камень диагностики в Linux. Однако без контроля файлы логов могут бесконечно расти, заполняя раздел /var и приводя к сбоям служб. Ротация логов — это автоматизированный процесс архивации, сжатия и удаления устаревших записей. Использование стандартной утилиты logrotate решает проблему с минимальными усилиями, экономя место и сохраняя историю событий в управляемом виде. После выполнения этого гайда вы получите работающую систему ротации как для системных логов, так и для логов ваших приложений.

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

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

1. У вас есть доступ к учетной записи с правами sudo.
2. Дистрибутив основан на Debian/Ubuntu или RHEL/CentOS/Fedora (конфигурация универсальна, но пути могут незначительно отличаться).
3. Установлена утилита logrotate (обычно есть по умолчанию). Проверить можно командой:

   logrotate --version
   

4. Вы знаете пути к лог-файлам, которые необходимо ротировать (например, /var/log/nginx/access.log).

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

Шаг 1: Изучение стандартной конфигурации

Главный конфигурационный файл — /etc/logrotate.conf. Откройте его в редакторе (sudo nano /etc/logrotate.conf). Типичное содержимое выглядит так:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

Ключевые параметры:

• weekly — частота ротации (daily, weekly, monthly, yearly).
• rotate 4 — хранить 4 архивированных файла, более старые будут удалены.
• compress — сжимать ротированные логи с помощью gzip (файлы получат расширение .gz).
• create — создавать новый пустой лог-файл после ротации.
• include /etc/logrotate.d — подключать дополнительные конфигурации из этой директории.

Это глобальные настройки по умолчанию. Для конкретных логов они могут переопределяться.

Шаг 2: Создание конфигурации для вашего приложения

Лучшая практика — создавать отдельные конфиги в /etc/logrotate.d/. Например, для веб-сервера Nginx, который пишет логи в /var/log/nginx/, или для кастомного приложения myapp.

1. Создайте файл конфигурации:

   sudo nano /etc/logrotate.d/myapp
   

2. Добавьте правило. Ниже пример для логов приложения в /var/log/myapp/:

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

   Разбор блока:
   • /var/log/myapp/*.log — путь к файлам, которые нужно ротировать (поддерживаются glob-шаблоны).
   • daily — ротировать каждый день.
   • missingok — не выдавать ошибку, если файл лога отсутствует.
   • rotate 14 — хранить 14 архивов (примерно две недели).
   • delaycompress — сжимать не сразу, а при следующей ротации (чтобы процессы, держащие файл, могли его закрыть).
   • notifempty — не ротировать пустые файлы.
   • create 644 myappuser myappgroup — после ротации создать новый файл с указанными правами и владельцем.
   • sharedscripts — выполнять скрипты postrotate/prerotate только один раз, а не для каждого файла.
   • postrotate ... endscript — команда, выполняемая после ротации. Здесь мы мягко перезагружаем службу myapp, чтобы она начала писать в новый файл. Это критично для многих демонов!

💡 Совет: Для логов, которые активно пишутся (например, access.log), всегда используйте postrotate с перезагрузкой/сигналом службы (kill -USR1 $(cat /var/run/nginx.pid)). Для статических файлов скрипты не нужны.

Шаг 3: Проверка синтаксиса и тестовый запуск

Не ждите следующего ежедневного cron-запуска. Проверьте конфигурацию:

1. Тестовый прогон (dry-run):

   sudo logrotate -d /etc/logrotate.conf
   

   
   Флаг -d включает режим отладки. Вы увидите, какие файлы будут ротированы и какие действия планируются, но никакие изменения не будут применены. Ищите в выводе строки running postrotate script и пути к вашим логам.
2. Принудительный запуск: Если тестовый прогон прошел успешно, выполните реальную ротацию:

   sudo logrotate -f /etc/logrotate.conf
   

   
   Флаг -f (force) заставляет logrotate выполнить ротацию независимо от времени, прошедшего с последнего запуска.
3. Проверка результата:
   • В директории логов (/var/log/myapp/) должны появиться сжатые архивы вида myapp.log.1.gz (последняя ротация) и myapp.log.2.gz и т.д.
   • Текущий активный лог (myapp.log) должен быть вновь создан (если использовали create).
   • Проверьте время модификации файлов: ls -laht /var/log/myapp/.

Шаг 4: Расписание (cron)

По умолчанию logrotate запускается из системного cron ежедневно через скрипт в /etc/cron.daily/logrotate. Изменить частоту можно, создав символическую ссылку в /etc/cron.hourly/, /etc/cron.weekly/ или добавив свою задачу в /etc/crontab. Однако обычно ежедневного запуска достаточно.

⚠️ Важно: Не запускайте logrotate слишком часто (например, каждый час) для логов с низкой интенсивностью. Это может привести к ротации пустых файлов и накоплению множества мелких архивов.

Шаг 5: Мониторинг и отладка

Если ротация не работает:

1. Проверьте права доступа к лог-файлам и директории /etc/logrotate.d/. Пользователь root должен иметь доступ.
2. Убедитесь, что в конфиге нет синтаксических ошибок (фигурные скобки должны быть сбалансированы).
3. Проверьте, не блокирует ли файл какая-либо программа. Иногда помогает параметр copytruncate (копирует файл и обнуляет оригинал, но может привести к потере записей во время копирования). Используйте его только если postrotate недоступен.
4. Посмотрите логи самого logrotate. Они обычно пишутся в syslog (/var/log/syslog или /var/log/messages). Ищите записи с тегом logrotate.

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

После выполнения шагов 2-3:

1. Убедитесь, что в целевой директории логов появились архивированные файлы с расширением .gz.
2. Размер текущего лог-файла (myapp.log) должен быть близок к нулю (если приложение продолжает писать) или равен размеру записей, появившихся с момента последней ротации.
3. Количество ротированных файлов (.log.1.gz, .log.2.gz...) не превышает значение rotate N.
4. Приложение продолжает корректно писать в новый лог-файл (проверьте, добавляются ли новые записи).

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

• Ошибка "error: error opening /var/log/myapp/*.log: No such file or directory"
  • Причина: Файл лога не существует на момент ротации.
  • Решение: Добавьте параметр missingok в конфигурационный блок. Это безопасно, если лог может создаваться приложением динамически.
• Логи продолжают бесконечно расти, ротация не происходит
  • Причина: logrotate не запускается по cron, или конфигурационный файл имеет неправильные права/имя.
  • Решение: Проверьте, что файл в /etc/logrotate.d/ имеет расширение .conf (не .txt). Запустите sudo logrotate -f /etc/logrotate.conf вручную и проверьте вывод.
• Приложение перестает писать в лог после ротации
  • Причина: Дескриптор файла у процесса приложения остался открытым на старом (удаленном) файле.
  • Решение: Обязательно используйте блок postrotate с командой, заставляющей приложение переоткрыть файл лога (например, systemctl reload, kill -USR1 или аналогичная команда для вашего ПО). Избегайте copytruncate для важных логов.
• Нет места на диске после ротации (из-за сжатия)
  • Причина: Процесс сжатия (gzip) создает временную копию файла, требуя свободного места, равного размеру исходного лога.
  • Решение: Убедитесь, что на разделе /var достаточно свободного места (хотя бы размер самого самого большого лога). В крайнем случае временно отключите compress в конфиге.
• Ротируются не те файлы
  • Причина: Неверный glob-шаблон в пути.
  • Решение: Проверьте шаблон командой ls /var/log/myapp/*.log. Убедитесь, что он соответствует нужным файлам и не захватывает лишние.

Продвинутые настройки (опционально)

• size 100M — ротировать не по времени, а когда файл достигнет указанного размера. Можно комбинировать с daily (ротация будет, если файл большой ИЛИ наступил день).
• maxsize 500M — ротировать, если файл больше этого размера, даже если не наступил период (например, daily + maxsize).
• olddir /var/log/myapp/archived — перемещать ротированные файлы в указанную поддиректорию (должна существовать).
• mail root — отправлять ротированные логи по почте (требует настроенный MTA).
• su root myappuser — выполнять ротацию от имени другого пользователя (полезно, если logrotate запускается от root, а логи принадлежат другому юзеру).

Эти параметры добавляются в блок конфигурации (например, /etc/logrotate.d/myapp).