logrotate для PHP-проекта: как не забить диск логами

Логи PHP-проекта могут расти незаметно: приложение пишет ошибки, nginx фиксирует запросы, PHP-FPM пишет предупреждения, cron складывает вывод в файл. Если ротация не настроена, один активный лог способен заполнить диск и остановить сайт.

logrotate нужен, чтобы ограничить срок и размер логов, сжимать старые файлы и не держать бесконечные app.log на сервере.

Найти логи проекта

Сначала нужно понять, какие файлы вообще пишутся.

find /var/www/site.ru -type f -name "*.log" -exec ls -lh {} \;
find /var/log -type f -name "*site*" -exec ls -lh {} \;

Типовые места:

• runtime/logs/app.log;
• local/logs/*.log;
• storage/logs/*.log;
• nginx access.log и error.log;
• PHP-FPM error.log;
• логи cron-задач.

Простой конфиг logrotate

Для логов приложения можно создать файл /etc/logrotate.d/site-app.

/var/www/site.ru/runtime/logs/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

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

copytruncate

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

Минус: небольшая часть записей может потеряться между копированием и обнулением. Для большинства простых PHP-логов это допустимо, но для критичных журналов нужно выбирать аккуратнее.

Права на новые файлы

Если logrotate создаёт новый файл, нужно задать владельца и права. Иначе приложение может перестать писать лог.

/var/www/site.ru/runtime/logs/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0644 www-data www-data
}

Пользователь и группа зависят от сервера. Это может быть www-data, nginx, apache или пользователь сайта.

nginx и postrotate

Для nginx после ротации обычно отправляют сигнал, чтобы он переоткрыл файлы логов.

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}

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

Проверить конфигурацию

Перед ожиданием ночного запуска можно проверить logrotate вручную в debug-режиме.

logrotate -d /etc/logrotate.d/site-app

Принудительный запуск:

logrotate -f /etc/logrotate.d/site-app

После него нужно проверить, что архивы созданы, а приложение продолжает писать в текущий лог.

Логи cron

Если cron пишет вывод в отдельный файл, его тоже нужно ротировать.

* * * * * cd /var/www/site.ru && php yii queue/run >> runtime/logs/cron.log 2>&1

cron.log может расти быстрее основного приложения, если команда падает каждую минуту.

Не хранить лишнее бесконечно

Ротация не заменяет контроль уровня логирования. Если приложение пишет megabytes debug-информации на каждый запрос, диск всё равно будет расходоваться быстро.

На production подробный debug лучше включать временно и точечно.

Чек-лист

1. Найти все *.log в проекте и на сервере.
2. Проверить, какие логи уже ротируются.
3. Добавить logrotate для логов приложения.
4. Указать rotate, compress, missingok, notifempty.
5. Выбрать copytruncate или create под способ записи логов.
6. Проверить владельца новых файлов.
7. Добавить ротацию cron-логов.
8. Проверить конфиг через logrotate -d.

logrotate — простая страховка от заполненного диска. Он не исправляет ошибки приложения, но не даёт логам бесконечно расти и превращать обычный warning в остановку сервера.