Сайт «моргнул» белым экраном, заказ не оформился, обмен с 1С внезапно перестал приносить остатки — и первый вопрос всегда один: где смотреть? Разработчик, который не умеет читать логи 1С-Битрикс, диагностирует проблемы вслепую: перезагружает страницы, гадает и правит наугад. А тот, кто знает, куда заглянуть, находит причину за минуты.
В этой статье — карта инструментов диагностики 1С-Битрикс: журнал событий, логи ошибок PHP, режим отладки, панель разработчика, отладка производительности и обмена с 1С. Разберём, какой инструмент за что отвечает и в каком порядке ими пользоваться. Системную диагностику сложных проектов мы ведём в рамках аудита и оптимизации 1С-Битрикс.
Коротко
- Логирование в Битрикс многослойное: журнал событий, логи PHP, статистика SQL, логи обмена — у каждого своя зона.
- На боевом сайте ошибки пишутся в файл, а не показываются на экране — показ ошибок на проде недопустим.
- Медленные страницы отлаживают панелью отладки и монитором производительности: время, число запросов, кэш.
- Логи разрастаются — настройте ротацию и чистку, но сохраняйте события безопасности для расследований.
Зачем нужны журнал и отладка
Диагностика — это половина работы поддержки любого проекта. Без выстроенного логирования каждая проблема превращается в детектив без улик: непонятно, что сломалось, когда и почему. Журнал событий и логи дают эти улики — фиксируют, что происходило на сайте в момент сбоя.
Хорошо настроенная диагностика решает три задачи: быстро находить причину ошибок, отслеживать подозрительную активность (события безопасности) и выявлять узкие места производительности до того, как они станут аварией. Всё это часть здоровой эксплуатации, наравне с CI/CD и деплоем и мониторингом инфраструктуры.
Слои логирования в 1С-Битрикс
Главное, что нужно понять: в Битрикс не один лог, а несколько слоёв, и они фиксируют разные вещи. Путать их — терять время.
| Слой | Что фиксирует | Где смотреть |
|---|---|---|
| Журнал событий | Прикладные и системные события платформы | Админка: Настройки → Инструменты |
| Логи PHP | Фатальные ошибки, warning, notice | error_log сервера |
| Статистика SQL | Медленные и ошибочные запросы | Настройки подключения к БД |
| Монитор производительности | Узкие места, кэш, тяжёлые компоненты | Модуль «Производительность» |
| Логи обмена с 1С | Протокол импорта CommerceML | Каталог обмена, настройки обмена |
Правильная диагностика начинается с вопроса «какого рода это проблема?» — и выбора нужного слоя. Ошибка прав — журнал событий. Белый экран — логи PHP. Тормоза — монитор производительности. Нет остатков — логи обмена.
Журнал событий: что и где
Журнал событий — прикладной слой. Он находится в административном разделе (Настройки → Инструменты → Журнал событий; путь чуть отличается по редакциям) и фиксирует события платформы:
- Действия с контентом. Изменения в модулях, публикацию и правки, если включено логирование.
- События безопасности. Попытки входа, ошибки прав доступа, подозрительную активность.
- Системные события. Изменения настроек, установку обновлений и модулей.
- Записи вашего кода. Всё, что вы добавляете через CEventLog::Add с нужным типом.
Это первое место, куда стоит заглянуть при непонятном поведении сайта: часто причина видна сразу — «кто-то поменял настройку», «пользователю не хватило прав». Настраивается объём фиксируемых событий в разделе настроек главного модуля.
Логи ошибок PHP и настройки
Технический слой — логи PHP. Сюда попадают фатальные ошибки (тот самый белый экран), warning и notice движка и вашего кода. На боевом сайте эти ошибки должны писаться в файл через error_log, а не выводиться на страницу.
Ключевые точки настройки:
- /bitrix/.settings.php — параметр exception_handling управляет обработкой исключений и режимом отладки.
- Настройки PHP — log_errors и error_log задают, куда пишутся ошибки движка.
- /bitrix/php_interface/dbconn.php — исторически здесь держали часть настроек логирования БД и подключения.
Умение читать эти логи критично при разборе аварий. Если проект интегрирован с внешними системами, к ним добавляются логи API — их безопасность и корректность мы разбирали в статье про REST, вебхуки и безопасность в Битрикс.
Режим отладки и показ ошибок
Здесь важнейшее правило безопасности: на боевом сайте показ ошибок на экране выключен. Вывод стека ошибок посетителю — это и утечка информации о структуре проекта, и испорченная вёрстка.
Как правильно:
- Прод — только в файл. Ошибки логируются в error_log, показ на экране отключён.
- Тест — можно на экран. Показывать ошибки прямо на странице допустимо только на закрытом от индексации тестовом контуре.
- Режим отладки точечно. debug=true включают на время диагностики, а не держат постоянно.
- Вернуть как было. После отладки настройки возвращают в боевой режим — забытый debug остаётся дырой.
Панель отладки и трассировка
Для разработчика в Битрикс есть встроенная панель отладки. Она показывает внизу страницы ключевые метрики выполнения:
- Время генерации страницы. Сколько заняла отработка PHP.
- Число запросов к базе. Ключевой индикатор: сотни запросов на страницу — тревожный знак.
- Трассировку компонентов. Какой компонент сколько времени и запросов потратил.
- Статистику кэша. Что взято из кэша, а что считалось заново.
Эта панель — быстрый способ понять, «здорова» ли страница. Если число запросов исчисляется сотнями, а время генерации велико — значит, где-то не работает кэш или компонент дёргает базу в цикле. Для чистой работы с базой в кастомном коде помогает D7 ORM — она делает запросы явными и управляемыми.
Отладка производительности
Когда сайт тормозит, нужен системный подход, а не догадки. Инструмент — модуль «Монитор производительности», который строит отчёт по узким местам:
- Медленные SQL-запросы. Показывает конкретные тяжёлые запросы, которые стоит оптимизировать.
- Повторный обход данных. Выявляет компоненты, которые ходят в инфоблоки в цикле вместо выборки разом.
- Эффективность кэша. Насколько используется кэширование компонентов и HTML-кэш.
- Общую оценку. Сравнение с эталоном, чтобы понять масштаб проблемы.
Отдельная большая тема — окружение: даже идеальный код тормозит на неправильно настроенном сервере. Как выстроена среда, мы разбирали в материале про инфраструктуру на BitrixVM.
Отладка обмена с 1С
Обмен с 1С по CommerceML — частый источник загадочных проблем: то остатки не приехали, то цены слетели, то товары задвоились. У обмена своё логирование, отдельное от остального сайта.
Как диагностировать:
- Включите подробный лог обмена. В настройках обмена активируется детальный протокол сеансов.
- Смотрите файлы протокола. В каталоге обмена появляются логи с ошибками разбора XML и сопоставления.
- Проверьте лимиты. Таймауты, память и размер шага выгрузки — частые причины обрыва обмена на больших каталогах.
- Сверьте структуру данных. Несоответствие свойств и типов в выгрузке ломает импорт.
На больших выгрузках чаще всего виноваты не «ошибки в коде», а инфраструктурные лимиты: сеанс упирается в таймаут или память. Поэтому отладку обмена ведут в связке с настройками сервера.
Логирование из своего кода
При разработке кастомной логики важно уметь логировать самому. В Битрикс для этого есть штатные инструменты:
- CEventLog::Add. Записывает прикладное событие в журнал событий с типом, модулем и описанием.
- AddMessage2Log. Пишет техническое сообщение в лог-файл модуля при включённом логировании — удобно для отладки.
- Собственный лог-файл. Для сложной логики заводят отдельный файл с понятным форматом записей.
Ротация и чистка логов
Логи полезны, но они разрастаются. Журнал событий и лог-файлы со временем занимают место на диске и замедляют админку. Гигиена логов:
- Ротация на сервере. Настройте logrotate, чтобы файлы не росли бесконечно.
- Срок хранения событий. В настройках Битрикс задаётся, сколько хранить записи журнала.
- Сохранение безопасности. События безопасности держат дольше — они нужны для расследования инцидентов.
- Контроль объёма. Периодически проверяйте, что логи не заполнили диск и не тормозят проект.
Частые ошибки
- Показ ошибок на проде. Стек ошибок виден посетителям — утечка и порча вёрстки.
- Диагностика не в том слое. Ищут проблему обмена в журнале событий вместо логов обмена и теряют время.
- Забытый режим отладки. debug=true остаётся включённым после разбора проблемы.
- Отладочный вывод в бою. var_dump и логи оставлены в боевом коде.
- Логи не ротируются. Файлы разрастаются и забивают диск.
- Нет мониторинга производительности. Тормоза замечают клиенты, а не команда.
Чек-лист диагностики
- Определите слой. Классифицируйте проблему: событие, ошибка PHP, тормоза или обмен.
- Загляните в журнал событий. Проверьте системные и охранные записи на момент сбоя.
- Прочитайте логи PHP. Найдите фатальные ошибки и warning в error_log.
- Включите панель отладки. Оцените время и число запросов на проблемной странице.
- Запустите монитор производительности. Найдите медленные запросы и провалы кэша.
- Проверьте логи обмена. Если проблема в данных из 1С — смотрите протокол импорта.
- Верните боевой режим. Отключите отладку и уберите временный вывод после диагностики.
Вывод
Отладка в 1С-Битрикс — это не магия, а знание, где искать. Логирование в платформе многослойное: журнал событий фиксирует прикладные и охранные события, логи PHP ловят технические ошибки, монитор производительности показывает узкие места, а обмен с 1С логируется отдельно. Умение выбрать нужный слой превращает многочасовой детектив в диагностику за минуты.
Соблюдайте главное правило безопасности — на боевом сайте ошибки пишутся в файл, а не на экран — и держите логи под контролем через ротацию. Тогда проблемы будут ловиться заранее, а не становиться авариями. Если диагностика проекта буксует, начните с системной настройки и автоматизации на 1С вместе с аудитом.
