Торговый каталог наполняется автоматически через парсер, но однажды утром вы обнаруживаете, что цены не обновлялись уже двое суток. Парсер упал в первый же час, а уведомления не пришли — стандартная почтовая очередь Битрикс забита, алерты не настроены. Потери выручки за два дня — около $900–1.3k. Знакомая ситуация? Мы решали её на 30+ проектах.
Без системы алертов любой парсер — бомба замедленного действия. Мы сталкивались с этим десятки раз: заказчик теряет выручку, потому что парсер тихо падает, а уведомления не приходят. Решение — настроить оповещения так, чтобы о проблеме узнавать в минуту сбоя, а не постфактум.
Почему штатные уведомления Битрикс не решают проблему?
Стандартные почтовые события Битрикс (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 (или b_option), не отправлялось ли такое же уведомление за последние N минут. Для сетевых — 30-60 минут подавления, для валидационных — без подавления.
Как дедуплицировать уведомления?
Дедупликация — ключевой элемент, чтобы не заспамить каналы. Мы используем Redis на каждой ноде: ключ — хеш от ERROR_TYPE + SOURCE_URL, значение — временная метка. Если такой хеш существует и не истёк, уведомление не отправляется. Для сетевых ошибок TTL 30 минут, для ошибок парсинга DOM — без подавления (каждый сбой уникален). Альтернатива — таблица b_option с сериализованным массивом, но Redis быстрее и не нагружает базу.
Каналы кроме почты
Email — медленный канал (доставка 2-5 минут). Для критичных ошибок подключаем Telegram Bot API или Битрикс24 вебхуки. Telegram отправляет за 1-2 секунды, Битрикс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 секунд — всё работает.
Как настроить алерты за 1 день?
Процесс занимает один рабочий день:
- Создаём почтовое событие PARSER_ERROR_NOTIFY и шаблон с макросами.
- Пишем класс
ParserNotifier::send()с дедупликацией и выбором канала. - Интегрируем Telegram Bot API или Битрикс24 вебхук.
- Настраиваем запись ошибок в
b_event_log. - Эмулируем сбой и проверяем доставку алерта.
После настройки вы получаете готовую систему оповещений с инструкцией по эксплуатации. Закажите настройку — мы проанализируем ваш парсер и настроим алерты за 1 день. Получите консультацию: наши инженеры помогут определить оптимальные каналы и пороги.