Настраиваем ротацию логов через logrotate!
Если приложение постоянно пишет в один файл, лог может незаметно вырасти до гигабайтов. В итоге диск заполняется, поиск ошибок становится медленнее, а сервис может начать падать просто из-за нехватки места.
Допустим, приложение пишет сюда:
/var/log/myapp/app.log
Для таких файлов удобно завести отдельное правило в logrotate.
Создадим конфиг:
sudo nano /etc/logrotate.d/myapp
Сначала указываем, какие логи нужно обрабатывать:
/var/log/myapp/*.log {
Теперь добавим ежедневную ротацию:
daily
Оставим только последние семь архивов:
rotate 7
Чтобы старые логи занимали меньше места, включим сжатие:
compress
Если файла временно нет, это не должно ломать весь запуск logrotate:
missingok
Пустой лог тоже нет смысла перекладывать в архив:
notifempty
Для простых приложений часто добавляют copytruncate. Он копирует текущий лог в архив, а исходный файл обрезает до нуля:
copytruncate
Это полезно, когда приложение не умеет переоткрывать лог-файл после сигнала. Минус тоже есть: в момент копирования можно потерять несколько строк, если приложение пишет очень активно.
В конце закрываем правило:
}
Перед применением лучше проверить конфиг в debug-режиме:
sudo logrotate -d /etc/logrotate.d/myapp
Так команда покажет, что собирается сделать, но не будет реально трогать файлы.
Если всё выглядит нормально, можно принудительно выполнить ротацию:
sudo logrotate -f /etc/logrotate.d/myapp
Потом проверяем каталог с логами:
ls -lh /var/log/myapp
В рабочей системе logrotate обычно запускается автоматически по таймеру или cron. Поэтому после настройки достаточно один раз проверить правило и дальше следить, что архивы появляются ожидаемо.
Такой подход помогает держать логи под контролем и не ждать момента, когда один шумный файл заполнит весь диск.
➡️ DevOps Ready | #практика
Если приложение постоянно пишет в один файл, лог может незаметно вырасти до гигабайтов. В итоге диск заполняется, поиск ошибок становится медленнее, а сервис может начать падать просто из-за нехватки места.
Допустим, приложение пишет сюда:
/var/log/myapp/app.log
Для таких файлов удобно завести отдельное правило в logrotate.
Создадим конфиг:
sudo nano /etc/logrotate.d/myapp
Сначала указываем, какие логи нужно обрабатывать:
/var/log/myapp/*.log {
Теперь добавим ежедневную ротацию:
daily
Оставим только последние семь архивов:
rotate 7
Чтобы старые логи занимали меньше места, включим сжатие:
compress
Если файла временно нет, это не должно ломать весь запуск logrotate:
missingok
Пустой лог тоже нет смысла перекладывать в архив:
notifempty
Для простых приложений часто добавляют copytruncate. Он копирует текущий лог в архив, а исходный файл обрезает до нуля:
copytruncate
Это полезно, когда приложение не умеет переоткрывать лог-файл после сигнала. Минус тоже есть: в момент копирования можно потерять несколько строк, если приложение пишет очень активно.
В конце закрываем правило:
}
Перед применением лучше проверить конфиг в debug-режиме:
sudo logrotate -d /etc/logrotate.d/myapp
Так команда покажет, что собирается сделать, но не будет реально трогать файлы.
Если всё выглядит нормально, можно принудительно выполнить ротацию:
sudo logrotate -f /etc/logrotate.d/myapp
Потом проверяем каталог с логами:
ls -lh /var/log/myapp
В рабочей системе logrotate обычно запускается автоматически по таймеру или cron. Поэтому после настройки достаточно один раз проверить правило и дальше следить, что архивы появляются ожидаемо.
Такой подход помогает держать логи под контролем и не ждать момента, когда один шумный файл заполнит весь диск.
➡️ DevOps Ready | #практика