Ротация логов и место на диске: настройка без сюрпризов

Ротация — это не просто удаление старых файлов

Лог-файл растёт, пока приложение пишет в него. Если диск закончится, последствия могут выйти далеко за пределы неудобного чтения логов: сервису станет некуда записывать временные файлы, базам данных — журнал изменений, а системе — новые данные. Удалять старый лог вручную опасно: приложение может продолжить писать в уже удалённый файл, который занимает место, хотя в каталоге его не видно.

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

Ротация работает правильно, только если после неё приложение пишет в новый файл, а старые копии ограничены по числу или сроку хранения.

Сначала определите, какой лог вы обслуживаете

Пример ниже рассчитан на файловые логи Nginx в Linux и logrotate 3.x. Версия logrotate и расположение конфигурации зависят от дистрибутива: проверьте установленную версию и штатные пути в документации своего Linux. На большинстве систем правила лежат в /etc/logrotate.d/, а общий конфигурационный файл — в /etc/logrotate.conf.

Перед настройкой выясните, куда именно приложение пишет, под каким пользователем создаёт файлы и как умеет перечитывать их после ротации. Для Nginx это сигнал USR1 главному процессу: он открывает файлы журналов заново. У другого приложения команда может быть другой.

• Посмотрите путь к логу в конфигурации приложения и проверьте его владельца и права.
• Уточните, каким пользователем работает сервис и доступен ли ему каталог для создания нового файла.
• Проверьте, что logrotate установлен и запускается автоматически по расписанию: конкретный механизм зависит от дистрибутива.
• Оцените темп роста файла и свободное место. Порог ротации не должен приближаться к объёму, который может заполнить раздел до следующего запуска logrotate.

Ротация¹ — создание новой версии файла журнала вместо записи в тот же файл бесконечно. Архивы можно хранить отдельно и сжимать.

Базовое правило для Nginx

Создайте правило для нужного файла, например в /etc/logrotate.d/nginx-local. Не заменяйте штатное правило дистрибутива, пока не проверили, что оно уже не обслуживает те же логи: два правила для одного файла способны вызвать конфликт.

/var/log/nginx/access.log /var/log/nginx/error.log {
    daily
    maxsize 200M
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl kill -s USR1 nginx.service
    endscript
}

В примере имена пользователя и группы, пути и имя systemd-службы нужно сверить с вашей системой. Если они отличаются, настройте правило под фактическую конфигурацию Nginx.

• daily задаёт периодическую ротацию раз в день при запуске logrotate.
• maxsize 200M разрешает ротацию, когда файл превысил указанный размер, но сам по себе не запускает logrotate немедленно. Если logrotate проверяет логи раз в сутки, большой файл может вырасти между проверками.
• rotate 14 ограничивает число сохранённых поколений, а не гарантирует ровно 14 календарных дней хранения.
• compress сжимает старые файлы, а delaycompress откладывает сжатие последнего архива до следующей ротации. Это полезно, если процесс ещё может дочитывать предыдущий файл.
• create 0640 www-data adm задаёт права, владельца и группу нового файла. Укажите значения, подходящие вашему сервису.
• sharedscripts запускает блок postrotate один раз для группы файлов, а не отдельно для каждого.

Команда в postrotate отправляет сигнал службе Nginx, чтобы та открыла новые файлы. Если служба называется иначе или работает не через systemd, эту строку нужно заменить на подходящий для вашего способа запуска механизм. Не копируйте правило вслепую.

Как выбрать между подходами

Для Nginx предпочтительнее переименование с повторным открытием: штатный механизм позволяет процессу продолжить работу с новым файлом. copytruncate оставьте для программ, которые нельзя заставить переоткрыть лог, и учитывайте риск потери записей.

Проверка: конфигурация должна пережить реальную ротацию

Не начинайте с принудительного запуска на рабочем сервере: он может изменить файлы раньше расписания. Сначала проверьте синтаксис и состояние, затем испытайте правило на тестовом файле или в тестовой среде. Опции командной строки и порядок проверки зависят от версии logrotate — сверьтесь с локальной справкой man logrotate.

1. Проверьте, что путь в правиле существует и совпадает с путём, который использует Nginx. Результат: правило охватывает именно нужные файлы, а не похожий путь.
2. Сверьте владельца, группу и режим доступа нового файла с пользователем процесса. Результат: сервис имеет право записывать в созданный лог.
3. Проверьте, что systemd-служба действительно называется nginx.service, а сигнал USR1 поддерживается вашей конфигурацией Nginx. Результат: команда из postrotate обращается к правильному процессу.
4. На тестовом стенде выполните ротацию и отправьте запрос к сервису. Результат: появился новый файл, в него записалась новая строка, архив старого файла сохранился.
5. Проверьте заполнение диска и число архивов после нескольких циклов. Результат: старые поколения удаляются, а суммарный объём логов остаётся в ожидаемых пределах.

Что ломается чаще всего

Приложение пишет в старый файл

Файл переименован, но процесс продолжает держать открытый файловый дескриптор. В каталоге новый лог есть, а его размер не растёт; место при этом занято удалённым или переименованным файлом. Проверьте, что команда в postrotate выполнилась и приложение действительно переоткрыло журнал.

У logrotate нет прав на создание файла

После ротации Nginx не может записывать в новый лог из-за неверного владельца, группы или режима. Проверьте значения в create по фактическому пользователю службы. Не расширяйте права до записи для всех пользователей без необходимости.

Размер файла превысил порог до следующей проверки

maxsize — условие при запуске logrotate, а не самостоятельный наблюдатель за размером. Если поток логов резко вырос, раз в сутки может быть недостаточно. Учащайте проверку с учётом нагрузки либо меняйте способ доставки и хранения логов.

Правило конфликтует со штатным

Один и тот же файл попал в два блока конфигурации. Проверьте штатные правила и сообщения logrotate при проверке. Оставьте для файла одно согласованное правило.

Журнал не является обычным файлом

Если сервис пишет в systemd journal, искать его в /var/log и добавлять в logrotate обычно не нужно. Для journald задают ограничения хранения в конфигурации systemd; конкретные параметры сверяйте с документацией установленной версии.

Что проверить дальше

После настройки следите не только за размером отдельных файлов, но и за свободным местом на разделе, возрастом последней ротации и сообщениями самого logrotate. Зафиксируйте ожидаемый объём архивов и проверьте его после нескольких циклов. Если лог растёт быстрее, чем вы успеваете реагировать, уменьшение срока хранения может не решить проблему: сначала выясните, какие события создают поток записей и нужен ли он целиком.

¹ Поколением называют текущий файл или одну из его архивных копий, созданных при последовательных ротациях.