Настройка уведомлений об ошибках парсинга 1С-Битрикс

Настройка уведомлений об ошибках парсинга 1С-Битрикс

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

Типы ошибок, которые нужно ловить

Прежде чем настраивать уведомления, стоит классифицировать ошибки:

• Сетевые — таймаут соединения, HTTP 403/429/503, сброс соединения. Источник парсинга недоступен или блокирует запросы.
• Парсинг DOM — изменилась вёрстка источника, CSS-селекторы или XPath-выражения возвращают пустоту. Самый частый тип.
• Валидация данных — цена равна нулю, название пустое, артикул не соответствует формату. Парсер получил данные, но они мусорные.
• Импорт в каталог — ошибки при вызове CIBlockElement::Add() или Update(), нехватка обязательных свойств инфоблока, превышение лимита по памяти.

Каждый тип требует своего уровня срочности. Сетевая ошибка может быть временной (повторить через 5 минут), а поломка селекторов — системная и требует вмешательства разработчика.

Архитектура уведомлений

Штатный механизм 1С-Битрикс для отправки сообщений — почтовые события (модуль main). Создаём тип почтового события, например PARSER_ERROR_NOTIFY, с шаблоном, содержащим макросы #ERROR_TYPE#, #SOURCE_URL#, #ERROR_MESSAGE#, #TIMESTAMP#. Шаблон регистрируется в разделе Настройки → Почтовые события → Типы событий.

Отправка из кода парсера:

CEvent::SendImmediate('PARSER_ERROR_NOTIFY', SITE_ID, [
    'ERROR_TYPE' => 'DOM_CHANGED',
    'SOURCE_URL' => $url,
    'ERROR_MESSAGE' => 'Селектор .price-block вернул пустой результат',
    'TIMESTAMP' => date('Y-m-d H:i:s'),
]);

Метод SendImmediate отправляет письмо сразу, минуя очередь b_event. Для парсерных ошибок это правильный выбор — задержка очереди может достигать нескольких минут.

Проблема спама: если источник лёг, парсер генерирует сотни одинаковых ошибок. Решение — дедупликация по ключу. Перед отправкой проверяем в b_option или отдельной таблице, отправлялось ли уведомление с таким ERROR_TYPE + SOURCE_URL за последние N минут. Интервал подавления — 30-60 минут для сетевых ошибок, без подавления для ошибок валидации.

Каналы кроме почты

Email — медленный канал. Для критичных ошибок подключаем Telegram или Slack через REST API Битрикс или напрямую:

• Битрикс24 вебхуки — если у вас есть портал Битрикс24, отправляйте сообщение в чат через im.message.add по входящему вебхуку. Уведомление придёт мгновенно в мобильное приложение.
• Telegram Bot API — file_get_contents('https://api.telegram.org/bot{TOKEN}/sendMessage?chat_id={ID}&text=...'). Простейший вариант без зависимостей.

Для каждого канала задаём порог срочности. Таблица маршрутизации:

Логирование как основа уведомлений

Уведомления строятся поверх логов, а не вместо них. Записывайте каждую ошибку в таблицу b_event_log через CEventLog::Add() с параметрами AUDIT_TYPE_ID = 'PARSER_ERROR' и MODULE_ID = 'iblock'. Это даёт историю в штатном журнале событий Битрикс (Настройки → Инструменты → Журнал событий), фильтрацию по типам и автоматическую ротацию.

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

Что настраиваем за один рабочий день

1. Тип почтового события + шаблон с переменными.
2. Обёртка ParserNotifier::send($type, $context) с дедупликацией.
3. Один дополнительный канал (Telegram или Битрикс24).
4. Запись ошибок в b_event_log для истории.
5. Проверка — эмуляция сбоя и подтверждение доставки алерта.