Логи и отладка в 1С-Битрикс: где искать ошибки сайта
Когда сайт на 1С-Битрикс работает нестабильно, не стоит начинать с догадок. Ошибки обычно уже где-то записаны: в PHP error log, nginx error log, журнале событий, логах cron, собственных debug-файлах или медленных SQL-запросах. Задача поддержки — быстро найти правильный источник.
Отладка на рабочем сайте должна быть аккуратной. Нельзя выводить ошибки пользователям, печатать var_dump на странице или писать в лог пароли и токены.
PHP error log
Fatal error, warning, parse error и проблемы с памятью часто попадают в PHP error log. Путь зависит от сервера.
tail -n 150 /var/log/php-fpm/error.log
tail -n 150 /var/log/php8.2-fpm.log
На shared-хостинге логи могут лежать в панели управления или в отдельной директории logs. Если на экране белая страница, начинать нужно именно с PHP-лога.
nginx или Apache
Если запрос не доходит до PHP, в логах Битрикс будет пусто. Тогда нужно смотреть веб-сервер.
tail -n 150 /var/log/nginx/error.log
tail -n 150 /var/log/nginx/access.log
В access.log удобно искать конкретный URL и код ответа:
grep "/catalog/test/" /var/log/nginx/access.log | tail
Debug::writeToFile
Для точечной отладки в Битрикс удобно использовать Debug::writeToFile. Это лучше, чем echo или var_dump на рабочей странице.
\Bitrix\Main\Diag\Debug::writeToFile(
[
'step' => 'before send mail',
'event' => $eventName,
],
'mail debug',
'/local/logs/mail_debug.log'
);
Директория local/logs должна существовать и быть закрыта от публичного доступа. Логи не должны хранить пароли, токены, полные данные карт и лишние персональные данные.
Журнал событий
В административной части Битрикс есть журнал событий. Там могут быть записи об авторизации, ошибках, изменениях и системных событиях. Он полезен, когда нужно понять, что происходило через админку.
Если проблема связана с входом, правами или действиями пользователя, журнал событий стоит проверить отдельно.
Логи агентов и cron
Фоновые задачи могут падать, даже если сайт открывается нормально. Для cron обязательно нужно писать stdout и stderr в лог.
* * * * * cd /var/www/site.ru && /usr/bin/php -f bitrix/modules/main/tools/check_agents.php >> local/logs/agents.log 2>&1
Потом проверка простая:
tail -n 100 local/logs/agents.log
Если лог не создаётся, нужно проверить пользователя cron и права на директорию.
SQL и производительность
Если сайт тормозит, ошибок может не быть. Тогда нужно смотреть медленные запросы, processlist и места, где шаблон делает дополнительные выборки.
SHOW FULL PROCESSLIST;
В коде старых шаблонов часто встречаются запросы внутри циклов:
grep -R "CIBlockElement::GetList" -n local/templates
grep -R "foreach" -n local/templates
Для серьёзной диагностики лучше использовать slow query log и инструменты производительности Битрикс.
Белый экран
Белый экран обычно означает fatal error, отключенный вывод ошибок или проблему на раннем этапе подключения. В этом случае:
- проверить PHP error log;
- проверить nginx error log;
- проверить последние изменения файлов;
- проверить синтаксис изменённых PHP-файлов;
- проверить права на файлы и кэш;
- проверить OPcache.
find local bitrix/php_interface -name "*.php" -print0 | xargs -0 -n1 php -l
Не включать показ ошибок надолго
На production не стоит показывать ошибки пользователям. Лучше писать их в лог.
display_errors = Off
log_errors = On
Временное включение подробной отладки допустимо только на закрытой копии или на очень короткое время с пониманием риска.
Чек-лист диагностики
- Проверить PHP error log.
- Проверить nginx или Apache error log.
- Найти проблемный URL в access.log.
- Добавить Debug::writeToFile для точечной проверки.
- Проверить журнал событий в админке.
- Проверить логи cron и агентов.
- Проверить SQL при проблемах со скоростью.
- Не выводить отладку пользователям.
Хорошая отладка Битрикс — это не хаотичные var_dump на странице, а понятные логи в нужном месте. Если фиксировать время, URL, ID сущности и короткую ошибку, причина обычно находится быстрее и без риска показать служебные данные пользователю.
Комментарии (0)
Пока нет комментариев. Будьте первым!