Журнал событий и логирование в 1С-Битрикс: как быстрее находить ошибки

Сообщение «не работает» редко содержит достаточно данных для разработчика. Ошибка могла появиться в PHP, базе данных, обмене, почте, авторизации или внешнем API. Чем сложнее проект, тем важнее заранее решить, где будут сохраняться диагностические события и какие данные попадут в запись.

В 1С-Битрикс есть системный журнал событий, а для собственного кода можно использовать отдельные логи. Эти инструменты решают разные задачи и лучше работают вместе.

Что даёт журнал событий Битрикс

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

Для собственных событий можно сохранять осмысленный тип, модуль, идентификатор объекта и краткое описание. Тогда журнал превращается из технического архива в инструмент расследования.

Не записывайте в лог всё подряд

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

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

Разделяйте уровни ошибок

• INFO — нормальное значимое событие, например завершение импорта;
• WARNING — операция выполнена, но обнаружено отклонение;
• ERROR — задача не завершилась или данные не обработаны;
• DEBUG — подробности, которые нужны временно во время диагностики.

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

Лог должен содержать контекст

Строка «API error» почти бесполезна. Намного полезнее запись, где есть название операции, ID объекта, endpoint или тип запроса, HTTP-код и время выполнения. Для фоновых процессов желательно добавлять уникальный идентификатор запуска, чтобы собрать все записи одной попытки в единую цепочку.

[sync:8f2a] start item=1257
[sync:8f2a] request status=200 duration=0.42s
[sync:8f2a] finish updated=1

Где искать проблему, если сайт показывает 500

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

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

Следите за размером логов

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

Что стоит логировать в первую очередь

• обмены с 1С и другими внешними системами;
• cron и долгие фоновые задания;
• отправку критичных уведомлений;
• ошибки оплаты и оформления заказа;
• нестандартные административные операции;
• изменения, которые трудно воспроизвести вручную.

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

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