Интеграции — самое хрупкое место любой экосистемы на базе Битрикс24. Сломался REST-вебхук из 1С, перестал работать коннектор телефонии, умер импорт лидов из рекламных кабинетов — бизнес не замечает это мгновенно. Проходит несколько часов или дней, прежде чем кто-то спотыкается о симптом: «куда делись заявки?», «почему оплаты не отражаются в CRM?».
Мы сталкивались с ситуацией, когда интеграция с Facebook Leads работала формально — код не падал, но токен доступа истёк, и новые лиды не импортировались двое суток. Клиент потерял 37 заявок, что при среднем чеке 15 000 рублей обернулось упущенной выручкой около 555 000 рублей. После этого мы внедрили мониторинг с проверкой токена каждые 30 минут и алертом в Telegram. С тех пор простой ни разу не превышал одного часа.
Как определить критичные интеграции?
Критичность интеграции определяется по двум критериям: объём данных и скорость реакции бизнеса. Платёжные шлюзы, синхронизация с 1С, лидогенерация — это красная зона. Внутренние системы, которые не влияют на операционку, можно проверять реже.
Все интеграции делятся на три уровня проверок:
- Уровень доступности: работает ли канал передачи данных? (REST endpoint отвечает, вебхук принимает запросы, очередь сообщений не переполнена)
- Уровень корректности: данные передаются без ошибок? (нет failed-записей в логах, значения полей соответствуют ожидаемым типам)
- Уровень актуальности: данные передаются вовремя? (последняя синхронизация была не более X минут назад, счётчик новых записей растёт)
Третий уровень часто игнорируют, и напрасно. Интеграция может «работать» технически, но данные приходить с 6-часовым опозданием из-за зависшего cron-задания.
Как настроить мониторинг встроенными средствами Битрикс24?
- Лог событий: Настройки → Журнал событий — здесь фиксируются ошибки REST API, сбои вебхуков, проблемы с модулями. Не самый удобный интерфейс, но информативный.
- Статус очереди вебхуков: в On-Premise можно посмотреть через таблицу
b_event_message_exec— накопление необработанных событий говорит о проблеме. - REST API лог: при наличии приложений на marketplace логи запросов доступны через Приложения → [приложение] → Логи.
Для базового мониторинга этого достаточно, но если интеграций больше трёх, лучше перейти к внешним системам.
Почему внешний мониторинг надёжнее?
Самый надёжный мониторинг — когда сама интеграция периодически «пингует» систему мониторинга и говорит «я жив». Схема через 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 отправляет уведомление, если сигнал не поступил в ожидаемое время. Это ловит «тихие» отказы — когда скрипт просто перестаёт запускаться.
Пошаговая настройка:
- Выберите систему мониторинга (Healthchecks.io или UptimeRobot).
- Для каждой интеграции создайте уникальный ping-URL.
- Добавьте в код интеграции вызов
file_get_contents(ping_url)после успешной синхронизации. - Настройте интервал проверки (обычно 10-30 минут).
- Настройте алерты: Telegram, Slack или email.
- Проверьте: остановите интеграцию вручную — должен прийти алерт.
Как мониторить REST API лимиты?
Битрикс24 имеет лимиты REST API (согласно REST API documentation): в облаке — 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 и значительно выше, но при интенсивных интеграциях всё равно стоит мониторить очередь.
Как создать дашборд состояния интеграций?
Создайте внутреннюю страницу-дашборд со статусом всех интеграций. Минимальный набор:
| Интеграция | Последняя синхронизация | Статус | Записей за 24ч |
|---|---|---|---|
| 1С → CRM (оплаты) | 5 мин назад | OK | 142 |
| Facebook Leads | 2 часа назад | WARN | 0 |
| Телефония (Mango) | 1 мин назад | OK | 89 звонков |
| Сайт (веб-формы) | 3 мин назад | OK | 23 лида |
Строится на базе таблицы b_option (где хранятся временные метки последней синхронизации) или отдельной БД мониторинга.
Сравнение методов мониторинга:
| Метод | Время реакции | Сложность настройки | Ловит «тихие» сбои |
|---|---|---|---|
| Встроенные логи | от 1 часа | низкая | нет |
| Ping-мониторинг | от 1 минуты | средняя | да |
| Полный дашборд | от 1 секунды | высокая | да |
Настройте алерты в мессенджер (Telegram-бот, Slack) — email читают редко, в мессенджер реагируют сразу. Для критичных интеграций (платежи, лиды с рекламы) SLA реакции на алерт — не более 15 минут в рабочее время.
Что входит в настройку мониторинга интеграций
Наша команда имеет более 8 лет опыта в Битрикс24 и реализовала более 50 проектов по мониторингу интеграций. В рамках услуги мы:
- Анализируем текущие интеграции и определяем критичные.
- Разрабатываем скрипты проверки (ping, валидация данных, замеры времени).
- Настраиваем дашборд и алерты в Telegram/Slack.
- Документируем процедуру добавления новой интеграции в мониторинг.
- Передаём доступы и инструкции вашей команде.
Гарантируем, что ни один сбой не останется незамеченным дольше 15 минут.
Получите консультацию: напишите нам, и мы оценим вашу систему интеграций за один день. Закажите аудит интеграций — мы покажем, какие проблемы скрыты сейчас.