Налаштування повідомлень про помилки парсингу 1С-Бітрікс

Налаштування сповіщень про помилки парсингу 1С-Бітрікс

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

Типи помилок, які потрібно ловити

Перш ніж налаштовувати сповіщення, варто класифікувати помилки:

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

Кожен тип вимагає свого рівня терміновості. Мережева помилка може бути тимчасовою (повторити через 5 хвилин), а поломка селекторів — системна та потребує втручання розробника.

Архітектура сповіщень

Штатний механізм 1С-Бітрікс для відправки повідомлень — поштові eventos (модуль 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. Перевірка — еміляція збою та підтвердження доставки алерта.