Как читать логи сайта и быстрее находить причину ошибки

В поддержке сайта логи помогают не спорить с симптомами. Пользователь говорит “форма не работает”, менеджер видит “заявка не пришла”, а в логе может быть конкретная строка: SMTP refused connection, validation failed, permission denied или missing column. Чем быстрее найдено точное сообщение, тем меньше случайных правок.

Где искать логи

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

• лог приложения: ошибки Yii2, исключения, пользовательские категории;
• лог nginx или Apache: ошибки веб-сервера, проблемы с FastCGI;
• лог PHP-FPM: падения процессов, превышение лимитов;
• почтовый лог: отправка и отклонение писем;
• логи cron и очередей: фоновые команды.

tail -n 100 runtime/logs/app.log
tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/php-fpm/error.log

На хостингах пути отличаются. Иногда error log лежит рядом с public_html, иногда доступен только через панель.

Смотреть лог во время повторения ошибки

Самый удобный способ — открыть лог в режиме ожидания и повторить действие на сайте. Так можно не искать нужную запись среди старых сообщений.

tail -f runtime/logs/app.log

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

Отделить свежую ошибку от старого шума

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

grep "2026-06-18" runtime/logs/app.log
grep "contact-form" runtime/logs/app.log
grep "Exception" runtime/logs/app.log

Если ошибка повторяется каждую минуту, возможно, её создаёт cron. Если появляется только при отправке формы, нужно смотреть обработчик формы и почту.

Что фиксировать при ошибке

Чтобы потом не возвращаться к той же диагностике, полезно сразу фиксировать минимум данных:

• точное время ошибки;
• URL или команда, где она возникла;
• текст исключения;
• файл и строка;
• последнее изменение кода или настроек;
• воспроизводится ли ошибка повторно.

Для Yii2 исключение обычно содержит stack trace. В нём важно найти не только строку во фреймворке, но и первый файл проекта, где началась проблема.

Логирование в Yii2

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

Yii::info([
    'email' => $model->email,
    'phone' => $model->phone,
], 'contact-form');

Yii::error($e->getMessage(), 'contact-form');

В рабочем проекте нельзя бездумно писать в лог персональные данные, токены, пароли и полные номера карт. Для диагностики обычно достаточно ID сущности, статуса, категории и короткого сообщения.

Когда лог пустой

Если ошибка есть, а лог приложения пустой, возможны несколько вариантов:

• приложение не успевает запуститься;
• не настроен target логирования;
• нет прав на запись в runtime/logs;
• ошибка возникает на уровне nginx или PHP-FPM;
• проверяется не тот сервер или не тот домен.

ls -la runtime/logs
touch runtime/logs/test.log

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

Ротация логов

Огромный app.log на несколько гигабайт — отдельная проблема. Его трудно читать, копировать и архивировать. В Yii2 можно настроить размер и количество файлов.

'log' => [
    'targets' => [
        [
            'class' => 'yii\log\FileTarget',
            'levels' => ['error', 'warning'],
            'maxFileSize' => 10240,
            'maxLogFiles' => 10,
        ],
    ],
],

Для серверных логов обычно используется logrotate. Проверять его стоит, если диск неожиданно заполняется логами.

Связь логов с обращением пользователя

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

1. Уточнить примерное время ошибки.
2. Открыть лог приложения за этот период.
3. Проверить веб-сервер на тот же момент.
4. Повторить действие на тестовых данных.
5. Сравнить новую запись в логе со старой.

Логи не заменяют понимание кода, но сильно сокращают путь к причине. Хорошая привычка при поддержке — сначала читать свежие сообщения, потом менять код. В обратном порядке легко исправить не ту проблему.