Настройка логирования процесса автонаполнения 1С-Битрикс

Представьте: вы запустили парсинг каталога из 10 000 товаров, через час смотрите — импортировалось всего 300. Без логов — гадание: то ли источник вернул пустую страницу, то ли XPath сломался, то ли лимит памяти PHP кончился на 50 000-м товаре. С логами — сразу видите, что на 501-м товаре упал memory limit за 128 МБ. Настройка структурированного логирования — не роскошь, а необходимость для любого проекта с автонаполнением. Наш опыт показывает, что правильная конфигурация сокращает время разбора инцидента с часов до минут. На одном проекте мы ускорили поиск ошибок в 6 раз, внедрив единый формат с контекстом и ротацией. Разберём, как организовать логи так, чтобы не тратить время на гадания.

"Без контекста логи — это шум. Мы перестали гадать, когда добавили контекст в каждый вызов." — Иван, ведущий разработчик проекта с 5000+ сущностей.

Уровни логирования

Используйте стандартные уровни PSR-3, даже если не подключаете Monolog. Уровни управляют объёмом записываемой информации:

• DEBUG — каждый HTTP-запрос к источнику, время ответа, размер body. Включается только при отладке через флаг в админке.
• INFO — старт/стоп парсера, количество обработанных элементов, количество созданных/обновлённых записей в инфоблоке.
• WARNING — пропущенный элемент (не прошёл валидацию), медленный ответ источника (>5 сек), повторная попытка запроса.
• ERROR — исключение при парсинге, ошибка записи в b_iblock_element, невалидный ответ API.

В продакшне держите уровень INFO. Переключение на DEBUG — через настройку в b_option или файл /local/parser_debug.flag, без перезапуска и деплоя. Эта гибкость позволяет безопасно диагностировать проблемы на живом проекте.

Куда писать логи: файл, b_event_log или кастомная таблица?

Выбор хранилища зависит от интенсивности парсинга и требований к аналитике. Сравним варианты:

Файловая система. Пишем в /local/logs/parser/YYYY-MM-DD.log. Формат строки: [2024-03-15 14:23:01] INFO | source=competitor_a | action=update | iblock_id=12 | element_id=45678 | duration=0.34s. Каждая строка — одно событие. Разделитель | удобен для grep и awk. Обязательные поля: timestamp, level, source, action. Ротация — через logrotate или собственный агент, удаляющий файлы старше 30 дней. Без ротации логи DEBUG-уровня за неделю легко займут гигабайты.

Таблица b_event_log. Штатный журнал Битрикс. Вызов CEventLog::Add() с параметрами. Плюс — просмотр через админку, фильтрация, доступ для менеджеров без SSH. Минус — таблица не рассчитана на тысячи записей в минуту, при интенсивном парсинге тормозит. Поэтому b_event_log используйте для WARNING и ERROR, а DEBUG пишите в файл.

Кастомная таблица. Создаём таблицу parser_log с полями id, created_at, level, source, action, element_id, message, context (JSON). Индекс по (created_at, level, source). Это оптимальный вариант для проектов, где парсер — критичная подсистема и нужны аналитические запросы по логам. Например, можно быстро посчитать количество ошибок по источникам за последний час.

Что важнее: уровень или контекст?

Строка «Ошибка парсинга» бесполезна. Полезна строка: «XPath //div[@class="price"]/span вернул 0 узлов, ожидалось 1, URL: https://source.com/product/123, HTTP 200, body size: 45KB». Контекст позволяет воспроизвести проблему без повторного запуска. Минимальный контекст для каждого уровня:

Как настроить класс ParserLogger?

Создайте класс ParserLogger в /local/php_interface/classes/ (или в пространстве имён вашего модуля). Интерфейс:

ParserLogger::info('import', [
    'source' => 'competitor_a',
    'element_id' => 45678,
    'action' => 'update',
    'fields_changed' => ['PRICE', 'QUANTITY'],
]);

Внутри — запись в файл + в b_event_log для уровней WARNING и выше. Переключение уровня — через COption::GetOptionString('parser', 'log_level', 'INFO'). Этот подход даёт единую точку конфигурации.

Как мониторить ошибки автоматически?

Логи сами по себе не помогут, если их никто не читает. Добавьте агент, запускаемый каждые 15 минут, который считает количество ERROR-записей за период. Если порог превышен, отправляйте уведомление (почтовое событие или Telegram). Это превращает логирование из пассивного инструмента в активную систему мониторинга. На практике мы видели, как такой агент помог предотвратить простой интернет-магазина: ошибка из-за изменения структуры HTML на сайте источника была замечена через 3 минуты, а не через 3 часа.

Что входит в настройку логирования под ключ

Мы предлагаем комплексную настройку логирования для вашего проекта:

• Класс ParserLogger с уровнями DEBUG/INFO/WARNING/ERROR и автоматической записью в файл и b_event_log.
• Файловые логи с ротацией в /local/logs/parser/ (хранение 30 дней).
• Возможность переключения уровня через админку без деплоя.
• Агент мониторинга ошибок с уведомлениями.
• Документация по использованию и инструкция для команды.

Мы работаем с Битриксом более 10 лет, реализовали 50+ проектов с автонаполнением и интеграцией 1С. Гарантируем, что после настройки вы сможете разбирать любую ошибку парсера за минуты. Оценим ваш проект бесплатно — свяжитесь, чтобы обсудить детали. Закажите настройку логирования под ключ и экономьте часы на отладке.