Мониторинг интеграций Битрикс24

Мониторинг интеграций Битрикс24

Интеграции — самое хрупкое место любой экосистемы на базе Битрикс24. Сломался REST-вебхук из 1С, перестал работать коннектор телефонии, умер импорт лидов из рекламных кабинетов — бизнес не замечает это мгновенно. Проходит несколько часов или дней, прежде чем кто-то спотыкается о симптом: «куда делись заявки?», «почему оплаты не отражаются в CRM?».

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

Что нужно мониторить

Каждую интеграцию можно разложить на три уровня проверок:

Уровень доступности: работает ли канал передачи данных? (REST endpoint отвечает, вебхук принимает запросы, очередь сообщений не переполнена)

Уровень корректности: данные передаются без ошибок? (нет failed-записей в логах, значения полей соответствуют ожидаемым типам)

Уровень актуальности: данные передаются вовремя? (последняя синхронизация была не более X минут назад, счётчик новых записей растёт)

Третий уровень часто игнорируют, и напрасно. Интеграция может «работать» технически, но данные приходить с 6-часовым опозданием из-за зависшего cron-задания.

Встроенные инструменты Битрикс24

Лог событий: Настройки → Журнал событий — здесь фиксируются ошибки REST API, сбои вебхуков, проблемы с модулями. Не самый удобный интерфейс, но информативный.

Статус очереди вебхуков: в On-Premise можно посмотреть через таблицу b_event_message_exec — накопление необработанных событий говорит о проблеме.

REST API лог: при наличии приложений на marketplace логи запросов доступны через Приложения → [приложение] → Логи.

Внешний мониторинг через ping-интеграции

Самый надёжный мониторинг — когда сама интеграция периодически «пингует» систему мониторинга и говорит «я жив». Схема через Healthchecks.io (или аналог):

// В скрипте интеграции (например, импорт лидов из рекламы)
function syncLeadsFromAds() {
    try {
        $leads = fetchLeadsFromFacebook();
        foreach ($leads as $lead) {
            CRest::call('crm.lead.add', $lead);
        }
        // Сигнал "всё хорошо" в систему мониторинга
        file_get_contents('https://hc-ping.com/your-uuid');
    } catch (Exception $e) {
        // Сигнал об ошибке
        file_get_contents('https://hc-ping.com/your-uuid/fail');
        logError($e->getMessage());
    }
}

Healthchecks.io отправляет уведомление, если сигнал не поступил в ожидаемое время. Это ловит «тихие» отказы — когда скрипт просто перестаёт запускаться.

Мониторинг REST API Битрикс24

Битрикс24 имеет лимиты REST API: в облаке — 2 запроса/секунду, лимит батч-запросов. При превышении возвращается QUERY_LIMIT_EXCEEDED. Мониторьте:

// Проверка текущего лимита через REST
$response = CRest::call('app.info');
// Ответ содержит REQUESTS_LEFT и TIME_RESET
$requestsLeft = $response['result']['REQUESTS_LEFT'];

if ($requestsLeft < 100) {
    sendAlert("Критически мало REST запросов: $requestsLeft");
}

Для On-Premise лимиты настраиваются в /bitrix/admin/settings.php и значительно выше, но при интенсивных интеграциях всё равно стоит мониторить очередь.

Дашборд состояния интеграций

Создайте внутреннюю страницу-дашборд со статусом всех интеграций. Минимальный набор:

Строится на базе таблицы b_option (где хранятся временные метки последней синхронизации) или отдельной БД мониторинга.

Настройте алерты в мессенджер (Telegram-бот, Slack) — email читают редко, в мессенджер реагируют сразу. Для критичных интеграций (платежи, лиды с рекламы) SLA реакции на алерт — не более 15 минут в рабочее время.