Ротация логов: как сохранять полезные данные без переполнения сервера

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Составьте карту журналов и их владельцев

Для каждого источника запишите, где находятся события, кто их создаёт, кто читает и каким механизмом управляется хранение. Отдельными источниками будут access log веб-сервера, ошибки приложения, системный журнал и события внешнего почтового сервиса. Одна настройка logrotate не управляет всеми этими системами.

Уточните формат времени и идентификатор для связывания событий. Если веб-сервер записывает локальное время, а приложение UTC, это должно быть явно известно. При расследовании важнее собрать последовательность одного запроса, чем иметь много несопоставимых строк.

Журналы не размещают внутри публично доступного каталога сайта. Доступ выдаётся по рабочей необходимости. Правила исключения секретов и ограничения персональных данных проверяют до увеличения сроков хранения: длительное хранение лишних сведений увеличивает последствия возможной утечки.

Считайте бюджет с учётом пиков

Оцените обычный и пиковый суточный прирост, затем выберите объём локальной истории и отдельного хранилища. Учебный пример: 200 МБ в день за 14 дней дают 2,8 ГБ несжатых событий. Это не размер необходимого раздела: к нему добавляются активные журналы, резерв на всплеск и временные файлы обработки. Предполагаемый коэффициент сжатия проверяют измерением.

Обсудите срок, за который команда обычно обнаруживает проблему. Если о пропавшей заявке сообщают через неделю, история за несколько часов мало помогает. Но хранение «навсегда» тоже не является решением. Для разных журналов допустимы разные сроки и уровни детализации, согласованные с владельцем данных.

Выберите один управляющий механизм

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

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

Для systemd-journald существуют собственные параметры объёма и свободного места. Они описаны в документации journald.conf; применимость и доступные опции сверяют с установленной версией. Бинарные файлы журнала не нужно включать в случайное правило ротации обычных текстовых логов.

Проверьте, куда процесс пишет после переименования

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

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

Режим copytruncate копирует содержимое, затем обнуляет исходный файл. Документация logrotate предупреждает о возможной потере событий в промежутке между этими действиями. Его нельзя считать равноценной заменой корректному переоткрытию без оценки требований к полноте журнала.

Начните с проверки без изменения файлов

Для GNU/Linux с установленным logrotate предусмотрен диагностический режим. Пример читает основную конфигурацию и включённые ею правила; если у системы другой путь, его уточняют заранее.

logrotate --debug /etc/logrotate.conf

Согласно руководству, этот режим не меняет журналы и файл состояния. Он помогает обнаружить синтаксические ошибки и увидеть решения инструмента, но не доказывает, что приложение правильно переоткроет файл при настоящей ротации. Диагностический вывод может содержать внутренние пути, поэтому его не публикуют целиком.

Реальное испытание выполняют на тестовой среде или в согласованное окно. До него создают контролируемое событие, после — ещё одно. Проверяют, где оказались обе записи, продолжает ли расти активный файл и читается ли архив. Отдельно проверяют доставку в удалённое хранилище, если оно участвует в схеме.

Учебный разбор: архивы появились, место продолжает уходить

Представим, что access log переименован и виден новый пустой файл. Через некоторое время старый журнал снова становится большим, а новый остаётся пустым. Такая картина направляет к проверке переоткрытия и владельца нового файла, а не к уменьшению срока хранения архивов.

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

Сохраните нужные события во время инцидента

При расследовании сбоя или взлома обычный срок удаления может оказаться слишком коротким. Ответственный выделяет нужный интервал и организует защищённое сохранение с учётом свободного места. Бессрочное отключение ротации на рабочем сервере создаёт риск нового отказа.

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

Проверяйте результат как отдельную операцию

• Запуск ротации виден, ошибки выполнения доходят до ответственного.
• Текущий журнал пополняется после смены файла, а архив больше не принимает новые события.
• Нужный период доступен для поиска; время и идентификаторы позволяют связать источники.
• Сроки удаления соблюдаются в каждом хранилище, включая внешние копии.
• Пиковый прирост оставляет запас диска до следующей проверки и реакции.

Такая проверка нужна после обновления сервиса, изменения пользователя процесса и переноса каталогов. Именно в этих точках ранее рабочее правило может перестать соответствовать реальному окружению.