Торговий каталог наповнюється автоматично через парсер, але одного ранку ви виявляєте, що ціни не оновлювалися вже дві доби. Парсер впав у першу ж годину, а сповіщення не прийшли — стандартна поштова черга Бітрікс забита, алерти не налаштовані. Втрати виручки за два дні — сотні тисяч рублів. Знайома ситуація? Ми вирішували її на 30+ проектах.
Без системи оповіщення про помилки будь-який парсер — бомба уповільненої дії. Ми стикалися з цим десятки разів: замовник втрачає виручку, тому що парсер тихо падає, а сповіщення не приходять. Рішення — налаштувати алерти так, щоб про проблему дізнаватися в хвилину збою.
Згідно з Wikipedia, веб-скрапінг потребує моніторингу помилок для запобігання збоям.
Чому штатні сповіщення Бітрікс не вирішують проблему?
Стандартні поштові події Бітрікс (CEvent::Send) часто не підходять: лист може йти кілька хвилин через чергу b_event, а при масових помилках поштова скринька забивається. Немає дедуплікації, немає маршрутизації за терміновістю. Потрібна кастомна обгортка.
Типи помилок, які потрібно ловити
Перш ніж налаштовувати сповіщення, класифікуємо помилки:
- Мережеві — таймаут з'єднання, HTTP 403/429/503, скидання з'єднання. Джерело недоступне або блокує. У 30% випадків проблема тимчасова, але 5+ підряд — системна.
- Парсинг DOM — змінилася верстка джерела: CSS-селектори або XPath повертають пустоту. Найчастіший тип (60% інцидентів).
- Валідація даних — ціна = 0, назва пуста, артикул не за форматом. Парсер отримав сміття.
- Імпорт в каталог — помилка
CIBlockElement::Add(), перевищення пам'яті, нестача властивостей.
Кожен тип потребує своєї терміновості. Мережева — затримка 5 хвилин і повтор, поломка селекторів — втручання розробника.
Архітектура сповіщень
Створюємо поштову подію 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 надсилає лист одразу, минаючи чергу. Додаємо дедуплікацію: перед відправкою перевіряємо в Redis, чи не було надіслано таке ж сповіщення за останні N хвилин. Для мережевих — 30-60 хвилин подавлення, для валідаційних — без подавлення.
Як дедуплікувати сповіщення?
Дедуплікація сповіщень — ключовий елемент, щоб не заспамити канали. Ми використовуємо Redis: ключ — хеш від ERROR_TYPE + SOURCE_URL, значення — часова мітка. Якщо такий хеш існує і не минув, сповіщення не надсилається. Для мережевих помилок TTL 30 хвилин, для помилок парсингу DOM — без подавлення. Альтернатива — таблиця b_option, але Redis швидше.
Канали крім пошти
Email — повільний канал (доставка 2-5 хвилин). Telegram доставляє сповіщення в 10 разів швидше за email, що робить його набагато кращим для критичних збоїв. Для критичних помилок підключаємо Telegram Bot API або Бітрікс24 вебхуки. Налаштовуємо таблицю маршрутизації за терміновістю:
| Тип помилки | Telegram | Бітрікс24 чат | |
|---|---|---|---|
| Мережева одинична | — | — | — |
| Мережева (>5 підряд) | + | + | — |
| Зміна DOM | + | + | + |
| Невалідні дані (>10%) | + | + | — |
| Помилка імпорту | + | + | + |
Telegram у 10 разів швидший за email для доставки — порівняння не на користь стандартної пошти.
| Канал | Типова затримка | Недоліки |
|---|---|---|
| Email (CEvent::Send) | 2-5 хв | Залежить від черги |
| Telegram Bot API | 1-2 сек | Потребує бота |
| Бітрікс24 вебхук | 0.5-1 сек | Тільки для on-premise |
Логування як основа сповіщень
Сповіщення — надбудова над логами. Кожну помилку пишемо в b_event_log через CEventLog::Add() з AUDIT_TYPE_ID='PARSER_ERROR'. Це дає історію в журналі, фільтрацію та ротацію. Агент раз на годину рахує помилки та надсилає дайджест, якщо поріг перевищено. Ми також забезпечуємо логування помилок парсингу для аналізу.
Приклад емуляції збою для перевірки
Для перевірки алертів ми імітуємо помилку: надсилаємо POST-запит з свідомо невірними даними в парсер. Наприклад, вказуємо неіснуючий URL або підсовуємо HTML без потрібних селекторів. Система надсилає сповіщення. Якщо воно приходить протягом 5 секунд — все працює.
Що входить в роботу
Ми пропонуємо рішення під ключ:
- Аналіз поточного парсера та типів помилок
- Налаштування поштової події PARSER_ERROR_NOTIFY
- Розробка класу ParserNotifier з дедуплікацією
- Інтеграція Telegram Bot API та/або Бітрікс24 вебхуків
- Налаштування логування помилок в b_event_log
- Тестування системи емуляцією збою
- Документація та інструкція з експлуатації
- Підтримка протягом 30 днів після налаштування
Як налаштувати алерти за 1 день?
Процес займає один робочий день:
- Створюємо поштову подію PARSER_ERROR_NOTIFY і шаблон.
- Пишемо клас
ParserNotifier::send()з дедуплікацією та вибором каналу. - Інтегруємо Telegram Bot API або Бітрікс24 вебхук.
- Налаштовуємо запис помилок до
b_event_log. - Емулюємо збій і перевіряємо доставку.
Після налаштування ви отримуєте готову систему оповіщення про помилки з інструкцією. Замовте налаштування — ми проаналізуємо ваш парсер і налаштуємо алерти за 1 день. Оцінимо проект безкоштовно — пишіть нам.