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

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

Парсер работает в фоне — через cron или агенты. Когда что-то идёт не так, единственный способ разобраться — логи. Без структурированного логирования отладка парсера превращается в гадание: то ли источник вернул пустую страницу, то ли XPath сломался, то ли лимит памяти PHP кончился на 50 000-м товаре. Разберём, как организовать логи, чтобы любой инцидент разбирался за минуты.

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

Используйте стандартные уровни PSR-3, даже если не подключаете Monolog:

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

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

Куда писать логи

Вариант 1: файловая система. Самый простой. Пишем в /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 (fetch/parse/validate/import).

Ротация — через logrotate или собственный агент, удаляющий файлы старше 30 дней. Без ротации логи DEBUG-уровня за неделю легко займут гигабайты.

Вариант 2: таблица b_event_log. Штатный журнал Битрикс. Вызов CEventLog::Add() с параметрами:

CEventLog::Add([
    'SEVERITY' => 'INFO',
    'AUDIT_TYPE_ID' => 'PARSER_IMPORT',
    'MODULE_ID' => 'iblock',
    'ITEM_ID' => $elementId,
    'DESCRIPTION' => json_encode($context, JSON_UNESCAPED_UNICODE),
]);

Плюсы — просмотр через админку, фильтрация, доступ для менеджеров без SSH. Минусы — таблица b_event_log не рассчитана на тысячи записей в минуту, при интенсивном парсинге тормозит. Используйте для WARNING/ERROR, не для DEBUG.

Вариант 3: кастомная таблица. Создаём таблицу 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 в /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). Это превращает логирование из пассивного инструмента в активную систему мониторинга.

Итог настройки за один день

1. Класс ParserLogger с уровнями DEBUG/INFO/WARNING/ERROR.
2. Файловые логи с ротацией в /local/logs/parser/.
3. Дублирование WARNING+ в b_event_log.
4. Переключение уровня через админку без деплоя.
5. Агент мониторинга ошибок в логах.