Ротация логов на сервере: типичные ошибки и их цена
Лог-файл может съесть место на диске, а неудачная ротация — оставить приложение писать в уже удалённый файл. Разбираем ошибки logrotate, сравниваем способы ротации и показываем, что проверить до запуска в проде.
Ротация логов должна освобождать место, не прерывая запись. Но если logrotate переименовал файл, а приложение продолжило писать в старый дескриптор, новый лог останется пустым, а удалённый файл — занимать диск. Ниже — типичные ошибки при настройке logrotate для Linux и критерии, по которым выбрать способ ротации.
Сначала проверьте, кто управляет логами
Пример настроек ниже ориентирован на logrotate 3.21.0. На сервере может стоять другая версия: перед изменениями проверьте её командой logrotate --version и сверьте синтаксис с локальной документацией.
Важно выяснить, откуда берутся логи. Приложение может писать в файл напрямую, отправлять сообщения в journald или передавать их системному syslog-сервису. В первых двух случаях настройка logrotate для произвольного файла может не затронуть нужные данные. Путь к журналам systemd настраивают средствами journald, а не правилами ротации файлов.
Перед настройкой соберите три факта: путь к активному логу, пользователя и группу, от имени которых приложение открывает файл, и способ, которым оно повторно открывает лог после ротации. Последнее обычно описано в документации приложения или пакетной конфигурации.
Три способа ротации — и их цена
| Способ | Преимущество | Риск | Когда уместен |
|---|---|---|---|
| Переименовать файл и создать новый | Обычно быстро; старый лог можно сжать отдельно | Процесс может продолжить писать в старый файл, пока не переоткроет его | Приложение умеет перечитывать или переоткрывать лог по сигналу или команде |
copytruncate | Не требует, чтобы приложение переоткрывало файл | Между копированием и очисткой записи могут потеряться; большой файл копируется целиком | Когда перезапуск или сигнал приложению невозможен, а риск короткого окна потери приемлем |
| journald | Сбор и ограничение журналов выполняются средствами systemd | Нужно учитывать политику хранения и способ чтения журнала; файлового архива по схеме logrotate может не быть | Когда приложение пишет в системный журнал |
Дескриптор файла — открытая процессом ссылка на файл. Переименование меняет имя в каталоге, но не обязано менять файл, в который уже пишет процесс.
Успешная ротация — не та, после которой появился файл с суффиксом. Успешная ротация — та, после которой приложение пишет в ожидаемый активный лог, а старый файл не удерживает место незаметно.
Ошибки, которые обнаруживаются слишком поздно
1. Переименовали лог, но не переоткрыли его
При стандартной схеме logrotate переносит активный файл в архив и создаёт новый. Процесс, который держит старый файл открытым, может продолжить запись в архив. Это особенно неприятно, если архив уже сжат: его размер растёт или файл продолжает занимать место после удаления имени.
Для приложений, умеющих переоткрывать логи, настройте соответствующее действие после ротации. Команду нельзя выбирать наугад: способ зависит от конкретного сервиса. Проверьте документацию и пакетное правило, прежде чем добавлять обработчик.
2. Считать copytruncate бесплатной страховкой
При этой схеме logrotate копирует содержимое в архив, а затем обнуляет исходный файл. Если приложение пишет как раз между копированием и очисткой, часть строк может не попасть ни в архив, ни в текущий лог. На больших файлах копирование также занимает время и создаёт дополнительную нагрузку на диск.
Не выбирайте этот вариант только потому, что он устраняет необходимость переоткрывать файл. Сначала оцените размер лога, скорость его роста и допустимость потери небольшого числа записей. Для аудита и критичных событий такой компромисс может быть неприемлем.
3. Создать новый файл с неверными правами
После ротации приложение должно получить доступ к новому логу. Если владелец, группа или режим доступа не совпадают с ожиданиями процесса, запись остановится. Директива create задаёт параметры нового файла; указывайте их по фактическому пользователю и группе сервиса, а не копируйте из чужого примера.
Не выдавайте права на запись всем пользователям сервера «для надёжности». Это может раскрыть логи или дать постороннему процессу возможность подменить содержимое. После первой ротации проверьте владельца и права нового файла.
4. Сжать файл раньше, чем приложение перестало его использовать
Сжатие уменьшает место под архивы, но не исправляет проблему с открытым дескриптором. Директива delaycompress откладывает сжатие последнего ротированного файла до следующего цикла. Она помогает при некоторых сценариях переоткрытия, но сама по себе не заставляет приложение переключиться на новый файл.
5. Проверить конфигурацию только на бумаге
Ошибку в правиле легко заметить тестовым запуском, а поведение приложения после реального переименования — нет. Учитывайте и расписание: конфигурация может быть корректной, но нужный таймер или cron-задача не запускает logrotate вовремя. Сначала выясните, как именно он вызывается в вашей системе.
Безопасная проверка перед боевым запуском
- Найдите правило и точный путь. Убедитесь, что правило относится к нужному файлу, а не к его архивам или похожему пути. Проверка: в конфигурации нет пересекающихся правил для одного и того же лога.
- Проверьте конфигурацию без изменений. Запустите logrotate с режимом отладки, указав нужный конфигурационный файл, если используете отдельное правило. Проверка: logrotate разбирает конфигурацию и показывает план действий без выполнения ротации.
- Сверьте права нового файла. После теста на безопасном стенде или в согласованное окно проверьте владельца, группу и режим доступа. Проверка: пользователь приложения может продолжить запись, а посторонние пользователи не получили лишних прав.
- Проверьте поведение процесса. После ротации убедитесь, что новые строки появляются в активном файле, а не только в архиве. Проверка: добавьте тестовое событие штатным способом приложения и найдите его в ожидаемом логе.
- Посмотрите, что осталось открытым. Если файл удалили или переименовали, но место на диске не освободилось, проверьте открытые дескрипторы средствами вашей ОС. Проверка: у процесса нет записи в удалённый ротированный файл.
Что выбрать и что контролировать
Для сервиса, который документированно умеет переоткрывать лог, обычно предпочтительна схема с переименованием и новым файлом: она избегает копирования всего содержимого. Для приложения без такого механизма copytruncate может оказаться практичным компромиссом, но его риск потери записей нужно принять явно. Если приложение пишет в journald, настройте ограничения и хранение журнала средствами systemd.
После настройки следите не только за наличием архивов. Контролируйте свободное место, рост активного файла, время выполнения ротации и ошибки приложения при записи. Если важна сохранность каждой записи, проверяйте не только размер файлов, но и то, что приложение корректно переключилось после ротации.
Что делать дальше
Начните с одного некритичного сервиса: зафиксируйте размер лога и права, проверьте правило в режиме отладки, затем проведите ротацию в согласованное окно и проследите за записью. После этого настройте оповещение о нехватке места и проверьте, как система ведёт себя при заполненном диске. Отдельный вопрос — централизованный сбор и долгосрочное хранение логов; он не заменяется ротацией локальных файлов.
Логотип и фирменный стиль: Три концепции разного характера, палитра с обоснованием, проверка на читаемость в малом размере и в один цвет.
Спросить за 60 ₽Источники: logrotate: документация и исходный код, systemd-journald.service: руководство systemd
Частые вопросы
Как понять, что приложение пишет в старый лог после ротации?
Можно ли всегда включать copytruncate?
Что делать, если logrotate сообщает об ошибке прав доступа?
Сработает ли пример на другой версии logrotate?
Нужно ли ротировать журналы journald через logrotate?
Почему архивы растут, хотя ротация настроена?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.