Ротация логов чтобы не забивался диск

MAATRIX

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

Почему логи забивают диск

Логи растут постоянно и незаметно. Веб-сервер пишет каждый запрос, приложение — каждое событие и ошибку, база данных — свой журнал, системные службы — свой. На нагруженном сайте access-лог nginx легко прибавляет сотни мегабайт в день, а если приложение сыплет ошибками в цикле, лог способен вырасти на гигабайты за часы. Пока места на диске много, это незаметно, но рано или поздно раздел заполняется, и всё, что пытается писать на диск, ломается.

Коварство в том, что переполненный диск валит сервисы разом и без явной связи с логами. База данных не может записать транзакцию, веб-сервер — временный файл, система — ничего. В логах при этом появляются странные ошибки, а настоящая причина — просто нет свободного места. Первым делом при непонятных сбоях всегда проверяйте занятость диска командой df -h: если раздел заполнен на 100%, вы нашли корень.

Находим, что именно разрослось

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

df -h
du -sh /var/log/* | sort -h

Первая команда показывает, какой раздел заполнен. Вторая выводит размеры всего внутри /var/log, отсортированные по возрастанию, — так вы сразу увидите виновника: раздутый access-лог, гигабайтный лог приложения или разбухший журнал systemd. Если нужно быстро освободить место прямо сейчас, самый большой лог можно обнулить, не удаляя файл, чтобы не сломать пишущий в него процесс:

truncate -s 0 /var/log/nginx/access.log

Это очищает содержимое, оставляя файл на месте. Удалять активный лог-файл через rm не стоит: процесс продолжит писать в удалённый дескриптор, и место не освободится до перезапуска службы. Обнуление через truncate безопаснее как экстренная мера.

Настройка logrotate

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

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

Разберём ключевые директивы. daily ротирует логи ежедневно, rotate 14 хранит две недели истории и удаляет то, что старше. compress сжимает старые логи gzip, экономя место в разы. copytruncate копирует лог и обнуляет оригинал на месте — это удобно для приложений, которые не умеют переоткрывать файл по сигналу. notifempty не ротирует пустые логи, missingok не ругается, если файла нет. Проверить конфиг без ожидания расписания можно в тестовом режиме:

logrotate -d /etc/logrotate.d/myapp

Ключ -d запускает отладочный прогон без реальных изменений и показывает, что logrotate собирается сделать. Убедившись, что всё верно, можно прогнать принудительно с ключом -f.

Ограничиваем журнал systemd

Отдельный частый пожиратель места — журнал systemd (journald), который на некоторых серверах разрастается до гигабайтов. Посмотрите его текущий размер и при необходимости почистите:

journalctl --disk-usage
journalctl --vacuum-size=500M

Первая команда показывает, сколько занимает журнал, вторая — ужимает его до полутора сотен мегабайт, удаляя самые старые записи. Чтобы журнал не разрастался впредь, задайте лимит в конфиге journald: откройте /etc/systemd/journald.conf, установите SystemMaxUse=500M и перезапустите службу. После этого journald сам будет держать размер в рамках, удаляя старое по мере поступления нового.

Выбор политики хранения

Сколько логов хранить — вопрос баланса между местом на диске и глубиной истории для расследования проблем. Слишком короткое хранение лишает вас данных, когда инцидент всплывает через неделю; слишком долгое — забивает диск. Разумная отправная точка для большинства проектов — две недели ежедневной ротации со сжатием: этого хватает, чтобы разобрать почти любой инцидент, и при этом объём остаётся управляемым благодаря компрессии.

Для нагруженных сервисов, где логи растут быстро, ротируйте не по расписанию, а по размеру: добавьте директиву size 100M, и logrotate будет крутить лог, как только он превысит заданный порог, независимо от времени суток. Это защищает от ситуации, когда за один день лог успевает вырасти на гигабайты и переполнить диск до наступления ночной ротации. Правильная политика хранения — важная часть эксплуатации сервера, и настроить её стоит один раз при запуске, а не после первого падения.

Отдельно стоит навести порядок на стороне самого приложения, а не только гасить симптомы ротацией. Очень часто логи раздуваются не из-за нормальной работы, а из-за неправильно выбранного уровня логирования: приложение пишет отладочные сообщения на боевом сервере, хотя в продакшене должно логировать только предупреждения и ошибки. Переключите уровень с debug на warning или error, и объём логов может упасть в десятки раз без всякой ротации. Вторая типовая причина разрастания — зацикленная ошибка: если приложение сыплет одним и тем же исключением по нескольку раз в секунду, никакая ротация не спасёт, потому что лог растёт быстрее, чем его успевают крутить. Такую ситуацию нужно ловить мониторингом и чинить корень, а не заливать проблему более агрессивной ротацией. Разумный уровень логирования плюс аккуратная обработка ошибок снимают большую часть нагрузки на диск ещё до того, как за дело берётся logrotate.

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

Профилактика переполнения диска

Ротация решает проблему логов, но диск может забить и что-то ещё: старые бэкапы, кеши, временные файлы, дампы базы. Заведите привычку следить за свободным местом. Настройте мониторинг, который шлёт оповещение при заполнении диска выше 80%, — это даёт запас времени среагировать до аварии. Периодически проверяйте тяжёлые директории через du, чистите старые бэкапы и временные файлы. Если же диск стабильно мал под ваши задачи даже после чистки и грамотной ротации, значит проекту нужен тариф с большим диском — нарастить его на VPS у MAATRIX можно без переезда, с оплатой из России картой или криптой.

Частые вопросы