Перейти к содержимому
BXWiki

Отладка на боевом сайте - журналы, режим ошибок, поиск виновника

Ищем причину сбоя на работающем сайте: смотрим журналы, включаем сообщения так, чтобы их не увидели посетители, и сужаем круг подозреваемых.

Решение

Начинаем с журналов, а не с правок:

Окно терминала
tail -100 /var/log/php-fpm/bx0-error.log | grep -iE 'fatal|error'
tail -50 /home/bitrix/www/bitrix/php_interface/error.log 2>/dev/null
tail -50 /var/log/nginx/error.log
# три журнала: процессы PHP, платформа и веб-сервер
# время в журналах сверяют между собой: часовой пояс сервера и сайта расходятся

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

Включаем показ сообщений безопасно:

/bitrix/.settings.php
'exception_handling' => ['value' => [
    'debug' => true,                     // подробные сообщения
    'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_DEPRECATED,
    'log' => ['settings' => ['file' => 'bitrix/modules/error.log']],
]],

Подробные сообщения на боевом сайте включают в журнал, а не на экран. Вывод ошибок посетителям показывает пути к файлам и куски запросов, и это подарок любому, кто как раз изучает ваш сайт.

Смотрим панель отладки на своей странице:

if ($USER->IsAdmin()) {
    define('BX_SHOW_STAT', true);        // время работы и число запросов
}
// панель показывают только себе: посетителям она не нужна и мешает

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

Сужаем круг отключением своего кода:

// /local/php_interface/init.php: комментируем подключения по одному
// require __DIR__ . '/handlers/catalog.php';
require __DIR__ . '/handlers/orders.php';
// сбой, исчезающий после отключения файла, найден
# пошаговый отладчик оставляют стенду: на боевом сайте он опасен

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

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

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

Типичные проблемы

Посетители видят пути к файлам и текст ошибки.

Показ ошибок включён для всех, а не в журнал. На боевом сайте подробности пишут в журнал, а не выводят на экран.

В журнале пусто, а сайт падает.

Смотрят не тот журнал: процессы PHP, платформа и веб-сервер пишут в разные файлы. Проверять нужно все три.

Ответ обмена или запроса сломался после включения отладки.

Отладочный вывод попадает в тело ответа. Для служебных адресов вывод отключают полностью.

Правка не влияет на поведение страницы.

Страница отдаётся из кэша. Проверку начинают со сброса кэша этой страницы.

После обновления сбой вернулся.

Он лечился правкой файла ядра. Обновление вернуло файл к исходному виду вместе с ошибкой.

Частые вопросы

Можно ли включить отладку только для себя?

Да, по признаку администратора или по адресу подключения. Посетители при этом видят обычную страницу.

Где искать ошибки своего кода?

В журнале платформы и в журнале процессов PHP. Свои сообщения удобно писать туда же, а не в вывод страницы.

Что делать с ошибкой, которая не повторяется?

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

Нужен ли отладчик на боевом сервере?

Нет, пошаговая отладка на боевом сайте останавливает процессы. Её место на копии, а на боевом остаются журналы.

Смежное

Первоисточник