Когда на сайте 1С-Битрикс падает форма заказа, обрывается интеграция с оплатой или админка выдаёт белый экран, разбор всегда начинается с одного вопроса: где смотреть логи. За несколько лет поддержки Bitrix-проектов у меня сложился конкретный маршрут - сначала лог ядра, потом PHP-лог сервера, потом режим отладки с выводом SQL-запросов. В девяти случаях из десяти ошибка на сайте Битрикс находится за 10-15 минут, если знать, куда смотреть, а не гадать по внешним симптомам.
Где искать логи ошибок в административной панели Битрикс
Первое место - не файлы на сервере, а сама админка. В разделе Настройки → Инструменты → Журнал событий (bitrix/admin/event_log.php) хранится история системных событий: неудачные авторизации, ошибки отправки почты, сбои модулей, критичные исключения PHP, если включена соответствующая опция. Журнал фильтруется по типу события, модулю и дате - для разбора конкретного инцидента это быстрее, чем перебирать текстовые логи руками.
Второе место - раздел Настройки → Инструменты → Проверка сайта. Штатный чекер прогоняет систему по десяткам параметров: права на файлы, версии модулей, настройки PHP, доступность внешних сервисов. Половина ошибок на сайте Битрикс, с которыми ко мне обращаются после «сайт вдруг перестал работать», находится именно здесь - просроченный SSL-сертификат, забитый диск на хостинге, отключенный модуль после обновления.
Если у сайта настроен модуль «Монитор производительности» (bitrix/admin/perfmon_settings.php), в нём отдельно копятся долгие SQL-запросы и PHP-исключения с трассировкой стека. Это первое, что я открываю при жалобах на «сайт тормозит», а не только при явных ошибках - таймауты часто маскируются под сбои формы или платежа.
Файловые логи ядра и режим отладки Bitrix
Штатный журнал в админке - это выжимка. Полная картина ошибки на сайте Битрикс собирается из файловых логов, которые лежат вне веб-доступной части:
/bitrix/php_interface/dbconn.php- здесь включается отладка соединения с БД/bitrix/modules/main/include/init_static.php- точка, где стартует ядро, полезна при白 white screen до вывода ошибок- каталог логов, который вы сами задаёте константой
BX_TEMPORARY_FILES_DIRECTORYили через переменную окружения - туда падают трассировки при включённом debug-режиме
Режим отладки включается в /bitrix/php_interface/dbconn.php или в отдельном файле подключений constant-ами:
define('BX_LOG_CSS', true);
define('DEBUG', true);
define('DEBUG_SQL', true);
$DBDebug = true;
$DBDebugToFile = true;
DEBUG_SQL и $DBDebug включают вывод всех SQL-запросов с временем выполнения - по этому логу видно, какой именно запрос падает по таймауту или синтаксической ошибке при кастомных компонентах. $DBDebugToFile пишет запросы не на экран, а в файл, что обязательно на боевом сайте - вывод отладки в браузер посторонним посетителям это уже утечка структуры БД.
Важный момент: после разбора ошибки константы нужно вернуть в false и удалить лог-файл. Оставленный включённым debug-режим на проде - это не только падение производительности из-за постоянной записи, но и потенциальный источник информации для тех, кто ищет уязвимости в структуре сайта.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Настройка PHP-логирования на сервере
Логи ядра Битрикс покрывают ошибки уровня CMS, но часть сбоев происходит на уровне PHP до того, как ядро успевает их перехватить - фатальные ошибки в кастомном коде компонентов, обрыв памяти, синтаксические ошибки после правки шаблона. Для них нужен системный error_log PHP.
В php.ini или в .htaccess (если хостинг это позволяет) включаю три директивы:
php_flag log_errors on
php_value error_log /home/user/logs/php_error.log
php_value error_reporting E_ALL
php_flag display_errors off
display_errors off обязателен на рабочем сайте - вывод ошибок прямо в HTML-страницу видят посетители, и это выглядит как минимум непрофессионально, как максимум раскрывает пути к файлам движка. Все ошибки должны идти в файл, который читаете только вы.
На большинстве хостингов с Битрикс (в том числе на 1С-Битрикс.Виртуальная машина) отдельно стоит проверить лог веб-сервера - /var/log/nginx/error.log или аналогичный путь в панели хостинга. Там видны 502 и 504 при обрыве PHP-FPM, ошибки прав доступа к файлам и проблемы с SSL, которые ядро Bitrix вообще не увидит, потому что запрос до PHP не доходит.
| Тип лога | Где искать | Что показывает |
|---|---|---|
| Журнал событий Bitrix | admin/event_log.php | Системные события, ошибки модулей, авторизации |
| Монитор производительности | admin/perfmon_settings.php | Долгие запросы, PHP-исключения со стеком |
| SQL-отладка ядра | файл через $DBDebugToFile | Все запросы к БД, синтаксис, время выполнения |
| PHP error_log | путь из php.ini | Фатальные ошибки, notice, warning в коде |
| Лог веб-сервера | /var/log/nginx или /var/log/apache2 | 502/504, обрыв PHP-FPM, ошибки прав доступа |
Диагностика сбоев в интеграциях: оплата, доставка, вебхуки
Отдельная категория ошибок на сайте Битрикс - не в самом движке, а на стыке с внешними сервисами. У интернет-магазинов на Bitrix чаще всего рвётся связка с эквайрингом и службами доставки: клиент оплачивает через Т‑Банк, получает списание, а заказ в CRM не создаётся, потому что вебхук с колбэком от платёжного шлюза не долетел или упал по таймауту на стороне сайта. То же самое с расчётом стоимости доставки СДЭК - виджет калькулятора тихо падает, если у API истёк токен или изменился формат ответа, а на фронте просто показывается пустое поле без внятной ошибки.
В таких случаях смотрю сразу два места: журнал событий Bitrix на предмет исключений в обработчике вебхука и лог самого модуля интеграции, если он пишет отдельно (это стоит уточнять в документации конкретного решения - многие платёжные модули для Bitrix ведут собственный лог транзакций). Если модуль молчит, ставлю временный error_log() прямо в обработчик входящего запроса - самый грубый, но самый надёжный способ понять, что вообще пришло от внешнего сервиса.
Если у вас на сайте нет готового решения под конкретную задачу - расчёт доставки, синхронизация остатков, кастомный обработчик оплаты - у меня в библиотеке готовых скриптов есть проверенные заготовки под типовые интеграции Bitrix, которые уже проходили через отладку на боевых проектах.
Ошибки cron-заданий и агентов Битрикс
Агенты (bitrix/admin/agent_list.php) - частый источник тихих сбоев: агент падает по исключению, но на фронте это никак не проявляется, просто перестаёт работать фоновая задача - например, рассылка или синхронизация каталога. В списке агентов видно дату последнего выполнения и количество попыток; если агент не выполнялся несколько дней при активном сайте, это почти всегда исключение внутри его кода, которое стоит смотреть через тот же error_log с включённым отображением стека вызовов.
Мониторинг ошибок вместо ручной проверки логов
Постоянно листать логи руками неэффективно, особенно на сайтах с трафиком, где ошибка может произойти ночью и остаться незамеченной до жалобы клиента. На проектах, где для меня это выгоднее по времени, ставлю связку из внешнего трекера ошибок (Sentry с PHP SDK для Bitrix ловит исключения в реальном времени с полным стеком) и уведомлений в Telegram или почту через простой вебхук - при появлении новой критичной ошибки прилетает сообщение сразу, а не через день, когда клиент напишет про пропавшие заказы.
Для более сложных сценариев мониторинга - например, когда нужно агрегировать ошибки сразу с нескольких источников (Bitrix, платёжный шлюз, склад) и присылать сводку раз в час - использую n8n: сценарий читает лог или API Sentry, фильтрует по критичности и пушит в чат. Настройка такой цепочки - это уже не разовая правка кода, а отдельная задача по автоматизации, которую я оцениваю от 25 000 ₽ в зависимости от количества источников и логики фильтрации.
Важно не путать мониторинг с диагностикой: трекер ошибок показывает, что что-то упало и где именно в коде, но причину - устаревший токен API, неверные права на файл, конфликт модулей после обновления - всё равно ищете по логам, которые разобраны выше.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Почему на сайте Битрикс белый экран без текста ошибки
Это значит, что display_errors выключен, а фатальная ошибка PHP оборвала выполнение скрипта до того, как ядро успело её обработать. Смотрите системный error_log PHP по пути из php.ini или в панели хостинга - там будет точная строка и файл, где произошёл сбой. Включать display_errors на боевом сайте ради разовой проверки можно, но сразу выключайте обратно после диагностики.
Как включить отладку SQL-запросов в Bitrix без вывода на экран
В файле подключения к БД задайте $DBDebug = true; и $DBDebugToFile = true; - все запросы с временем выполнения уйдут в файл, а не в браузер. После разбора проблемы обе константы возвращайте в false, иначе лог будет расти на каждом хите и займёт лишнее место на диске.
Где смотреть ошибки, если сайт вообще не открывается
При полном отказе сайта сначала проверяйте лог веб-сервера (nginx или apache), а не логи Bitrix - ядро CMS просто не успевает загрузиться, если PHP-FPM упал, диск переполнен или истёк SSL-сертификат. Штатный инструмент «Проверка сайта» в админке тоже недоступен в этом случае, поэтому доступ к серверным логам через панель хостинга или SSH обязателен.
Нужно ли держать режим отладки включённым постоянно
Нет. Постоянно включённый DEBUG и вывод SQL-запросов в файл увеличивают нагрузку на диск и создают файл с чувствительными данными о структуре БД. Включайте отладку точечно на время диагностики конкретной ошибки на сайте Битрикс и выключайте сразу после того, как причина найдена - для постоянного контроля используйте журнал событий и внешний трекер вроде Sentry, а не встроенный debug-режим ядра.