Ротация логов перед продакшеном: чек-лист и расчёт диска

Перед запуском в продакшен проверьте не только расписание ротации, но и то, кто именно пишет каждый лог и как приложение открывает файл заново. Иначе диск может заполниться между запусками logrotate, а после переименования файла сервис продолжит писать в удалённый inode. Ниже — чек-лист для Linux-сервера и logrotate 3.21.0: он помогает обнаружить эти проблемы до того, как они превратятся в 500-ю ошибку или остановку сервиса.

Сначала составьте карту логов

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

• Файлы приложения. Уточните у разработчиков, пишет ли процесс прямо в файл или в stdout/stderr, умеет ли он перечитать файл после сигнала или команды.
• Системные журналы. Если логи хранятся в journald, ими управляют настройки и инструменты systemd, а не правило logrotate для файлов приложения.
• Контейнеры. У Docker Engine логи контейнера могут обрабатываться выбранным logging driver. Например, ротация файлов драйвера json-file — отдельная настройка; правило logrotate в каталоге приложения её не заменяет.
• Внешние сборщики. Проверьте, не отправляются ли те же записи одновременно в локальный файл и в систему централизованного хранения. Дублирование повышает расход диска.

Зафиксируйте также, на каком разделе лежит каждый путь. Если каталог логов — символическая ссылка или отдельная точка монтирования, проверьте фактическую файловую систему, а не только путь в конфиге.

Выберите способ ротации по поведению приложения

Для logrotate важна не только команда «переименовать и создать файл», но и то, что процесс делает после неё. Сравните варианты до того, как закрепите конфигурацию.

Не запускайте два независимых механизма ротации для одного файла. Например, если приложение уже само переименовывает логи, правило logrotate для того же пути может дать гонку, неожиданные имена файлов или пропуск данных.

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

Посчитайте место, а не угадывайте срок хранения

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

Для грубой оценки используйте измеренные значения за репрезентативный период:

Требуемое место ≈ активные логи + объём записей за период до следующей проверки × срок хранения + запас на всплеск и служебные данные.

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

Термин — inode. Это запись файловой системы, которая хранит метаданные файла. Раздел может исчерпать inode и перестать создавать файлы, даже если свободные гигабайты ещё есть.

Чек-лист перед запуском

1. Найдите все источники. Сопоставьте файлы приложения, журналы systemd и контейнерные логи с механизмом, который ими управляет. Проверка: для каждого источника записаны путь или logging driver и ответственный за ротацию.
2. Зафиксируйте требования к хранению. Узнайте, сколько времени записи должны оставаться доступными для диагностики или внутреннего процесса. Проверка: срок подтверждён владельцем сервиса, а не выбран по привычке.
3. Измерьте рост. Снимайте размер каталогов и скорость прироста в обычный день и во время ожидаемого пика. Проверка: расчёт использует наблюдения, а не одну точку замера.
4. Проверьте механизм повторного открытия. Для ротации через переименование найдите документированную команду или сигнал именно для вашего приложения. Проверка: после тестовой ротации новые записи появляются в новом файле.
5. Проверьте права. Сверьте владельца и режим доступа нового файла с тем, от чьего имени работает сервис. Проверка: процесс записывает в новый файл, а посторонний пользователь не получает лишний доступ.
6. Проверьте расписание. Убедитесь, что logrotate действительно запускается на этом сервере, а не только установлен. Способ планирования зависит от дистрибутива и его конфигурации. Проверка: есть подтверждение успешного запуска в журнале или системе мониторинга.
7. Испытайте конфигурацию вне рабочего сервиса. В logrotate 3.21.0 режим --debug позволяет проверить ход обработки без выполнения изменений: например, logrotate --debug /etc/logrotate.conf. Проверка: вывод не содержит ошибок разбора и показывает ожидаемые правила. Принудительную ротацию сначала проверяйте на стенде: она меняет файлы и может затронуть работающий процесс.
8. Настройте сигнализацию. Отслеживайте свободное место и inode на разделе с логами, а также размер и возраст последних файлов. Проверка: тестовое превышение порога создаёт уведомление до того, как сервис теряет возможность писать.

Что ломается в реальной эксплуатации

Сервис пишет в удалённый файл

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

Ротация настроена, но диск всё равно заполняется

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

Ротация раз в сутки не спасает от всплеска

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

Логи съедают место после удаления старых копий

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

Что делать дальше

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

Ротация не заменяет сбор и резервное хранение логов, если они нужны для расследований или обязательного хранения. Централизованный сбор логов — отдельная задача; здесь речь только о контроле локального диска.