Разработка системы оповещений для администраторов 1С-Битрикс

Разработка системы оповещений для администраторов 1С-Битрикс

Администратор Битрикс-сайта должен узнавать о критических событиях быстро: новый заказ, ошибка оплаты, заполненная форма обратной связи, падение агента, превышение дискового квоты. Стандартные почтовые события Битрикса покрывают часть этих сценариев, но для полноценной системы оповещений их недостаточно.

Стандартные почтовые события Битрикса

Ядро Битрикс использует механизм почтовых событий: код события → шаблон письма → получатели. Все события регистрируются в таблице b_event, шаблоны — в b_event_message, а история отправленных писем (при включённом логировании) — в b_event_log.

Для e-commerce критичные события уже существуют: SALE_ORDER_NEW (новый заказ), SALE_ORDER_PAID (оплата получена), SALE_ORDER_CANCEL (отмена). Получателей настраиваете в шаблоне события через /bitrix/admin/sale_delivery_handler.php или через модуль main → «Почтовые события».

Проблема стандартного механизма: письма уходят синхронно в момент события, что тормозит ответ сервера при медленном SMTP. Решение — очередь отправки через таблицу b_email_service или внешний SMTP с быстрым соединением.

Кастомные оповещения через события модулей

Для нестандартных сценариев вешаетесь на события модулей в init.php. Перечень полезных точек:

Новая заявка из формы — OnAfterAddResult модуля form:

AddEventHandler("form", "OnAfterAddResult", function($formId, $resultId, $arResult) {
    if ($formId == CALLBACK_FORM_ID) {
        notifyAdmin('Новая заявка #' . $resultId, formatFormData($arResult));
    }
});

Ошибка в агентах — агенты в b_agent выполняются без явного логирования. Оборачивайте код агента в try-catch и при исключении отправляйте уведомление:

function MyModuleAgent() {
    try {
        // код агента
    } catch (\Throwable $e) {
        notifyAdmin('Ошибка агента', $e->getMessage() . "\n" . $e->getTraceAsString());
    }
    return __FUNCTION__ . '();';
}

Превышение лимитов диска — в Битриксе есть агент CIBlockAgent::CheckDiskQuota(). Его можно переопределить или дополнить своим агентом, проверяющим размер директорий и отправляющим alert при превышении порога.

Ошибки оплаты — событие OnSalePaymentUpdate с проверкой смены статуса на ошибочный:

AddEventHandler("sale", "OnSalePaymentUpdate", function($id, &$arFields) {
    if ($arFields['IS_RETURN'] === 'Y' || strpos($arFields['PS_STATUS_MESSAGE'], 'error') !== false) {
        notifyAdmin('Ошибка оплаты заказа', print_r($arFields, true));
    }
});

Многоканальная доставка оповещений

Email — базовый канал, но не всегда достаточно быстрый. Для критичных уведомлений добавляйте:

Telegram-бот. Создаёте бота через BotFather, получаете BOT_TOKEN и CHAT_ID администраторского чата. Отправка через \Bitrix\Main\Web\HttpClient:

function notifyTelegram(string $message): void {
    $botToken = COption::GetOptionString('local', 'telegram_bot_token');
    $chatId = COption::GetOptionString('local', 'telegram_admin_chat_id');

    $httpClient = new \Bitrix\Main\Web\HttpClient();
    $httpClient->post(
        "https://api.telegram.org/bot{$botToken}/sendMessage",
        ['chat_id' => $chatId, 'text' => $message, 'parse_mode' => 'HTML']
    );
}

Храните токены в b_option через COption, не в коде — при ротации токена не нужно искать по файлам.

SMS через API. Для действительно критичных событий (недоступность платёжного шлюза, взлом попытки) — SMS через SMSC.ru или SMS.ru. Те же HttpClient + API-ключ.

Push-уведомления в браузер. Для оповещений, когда администратор в административной панели — через системный Bitrix Push Server (push.1c-bitrix.ru) или через Web Push API с VAPID-ключами (см. отдельную реализацию).

Центр уведомлений в административной панели

Помимо внешних каналов, полезен внутренний «журнал уведомлений» прямо в /bitrix/admin/. Реализуется как инфоблок или кастомная таблица b_local_notifications с полями TYPE, MESSAGE, IS_READ, DATE_CREATE.

В административном меню добавляете ссылку на список уведомлений через /bitrix/admin/menu_ext.php. Непрочитанные уведомления показываются счётчиком в боковом меню через кастомный административный виджет.

Фильтрация и приоритеты

Не все события одинаково важны. Выстраивайте приоритеты:

• Критично → немедленно → Telegram + SMS: падение сайта, ошибка оплаты, взломная активность
• Важно → в течение часа → Email: новый заказ, новая заявка, окончание срока лицензии
• Информационно → дайджест раз в день → Email: статистика заказов, новые регистрации, активность форм

Дайджест реализуется через агент: собирает события за сутки из лога, формирует письмо и отправляет в 9:00 следующего дня. Это снижает информационный шум для менеджеров.

Мониторинг технического состояния

Отдельная категория оповещений — техническое состояние сайта:

• Доступность сайта — внешний мониторинг (UptimeRobot, Zabbix) важнее внутреннего, потому что при падении сервера внутренние агенты не отработают
• Ошибки PHP — настройте запись в файл + агент, читающий файл ошибок и отправляющий новые критические записи администратору
• Размер очереди задач — таблица b_agent: если записей с NEXT_EXEC в прошлом накапливается больше нормы, что-то не работает

Таблица b_event_log при включённом логировании быстро растёт. Настройте регулярную очистку через агент или крон: удаляйте записи старше 30 дней, сохраняя только критичные события.