Інтеграції — найвразливіше місце будь-якої екосистеми на базі Бітрікс24. Зламався REST-вебхук із 1С, перестав працювати конектор телефонії, помер імпорт лідів із рекламних кабінетів — бізнес не помічає це миттєво. Минає кілька годин або днів, перш ніж хтось натикається на симптом: «куди поділися заявки?», «чому оплати не відображаються в CRM?».
Ми стикалися з ситуацією, коли інтеграція з Facebook Leads працювала формально — код не падав, але токен доступу закінчився, і нові ліди не імпортувалися дві доби. Клієнт втратив 37 заявок, що при середньому чеку $140–200ів обернулося втраченим виторгом близько $5k–7.2kів. Після цього ми впровадили моніторинг із перевіркою токена кожні 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 хвилин.
Отримайте консультацію: напишіть нам, і ми оцінимо вашу систему інтеграцій за один день. Замовте аудит інтеграцій — ми покажемо, які проблеми приховані зараз.
