Мониторинг интеграций Битрикс24: система раннего предупреждения сбоев

Интеграции — самое хрупкое место любой экосистемы на базе Битрикс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 отправляет уведомление, если сигнал не поступил в ожидаемое время. Это ловит «тихие» отказы — когда скрипт просто перестаёт запускаться.

Пошаговая настройка:

1. Выберите систему мониторинга (Healthchecks.io или UptimeRobot).
2. Для каждой интеграции создайте уникальный ping-URL.
3. Добавьте в код интеграции вызов file_get_contents(ping_url) после успешной синхронизации.
4. Настройте интервал проверки (обычно 10-30 минут).
5. Настройте алерты: Telegram, Slack или email.
6. Проверьте: остановите интеграцию вручную — должен прийти алерт.

Как мониторить 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 и значительно выше, но при интенсивных интеграциях всё равно стоит мониторить очередь.

Как создать дашборд состояния интеграций?

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

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

Сравнение методов мониторинга:

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

Что входит в настройку мониторинга интеграций

Наша команда имеет более 8 лет опыта в Битрикс24 и реализовала более 50 проектов по мониторингу интеграций. В рамках услуги мы:

• Анализируем текущие интеграции и определяем критичные.
• Разрабатываем скрипты проверки (ping, валидация данных, замеры времени).
• Настраиваем дашборд и алерты в Telegram/Slack.
• Документируем процедуру добавления новой интеграции в мониторинг.
• Передаём доступы и инструкции вашей команде.

Гарантируем, что ни один сбой не останется незамеченным дольше 15 минут.

Получите консультацию: напишите нам, и мы оценим вашу систему интеграций за один день. Закажите аудит интеграций — мы покажем, какие проблемы скрыты сейчас.

Техподдержка 1С-Битрикс: с чего начинается реальная помощь

Обмен с 1С через \Bitrix\Sale\Exchange встал в пятницу вечером. Остатки на сайте — вчерашние, клиенты заказывают товар, которого нет. Менеджер пишет в чат «1С не грузится», но проблема — в PHP-процессе, который упал по memory_limit при импорте 40 000 SKU. На диагностику и исправление нужно 20 минут, если знаешь, куда смотреть. Без поддержки — до понедельника сайт торгует воздухом. Мы — команда с 7-летним опытом обслуживания проектов на 1С-Битрикс. За это время провели более 50 успешных внедрений и спасли не один сайт от простоев.

Почему техподдержка 1С-Битрикс критична?

Битрикс — живой продукт. Выходят патчи безопасности, меняются версии модулей, кастомизированные решения требуют совместимости. Чем дольше сайт живёт без обслуживания, тем выше риск:

• Уязвимости. Битрикс выпустил патч для модуля vote (CVE-2022-XXXX). Без поддержки его ставят «когда руки дойдут» — через 3 месяца. За это время сайт могут взломать. Мы накатываем критические патчи в течение 48 часов — но только после проверки на staging, потому что обновление main до 24.x ломало CIBlockElement::GetList с кастомными свойствами.
• Лицензия. Истекла — потеря доступа к обновлениям и маркетплейсу. Отслеживаем сроки, уведомляем за 60/30/14 дней.
• Мониторинг. Не просто «сайт пингуется». Проверяем ключевые сценарии: добавление в корзину (sale.basket.add), оформление заказа, обмен с 1С, работа поиска. Если API 1С вернул 500, а страница отдаёт 200 — пинг-мониторинг этого не увидит.
• Бэкапы. Создаются автоматически, но кто проверяет восстановление? Раз в квартал разворачиваем на тестовом сервере и прогоняем smoke-тесты.

Обновление ядра раз в месяц снижает количество уязвимостей в 3 раза по сравнению с ежеквартальным подходом. Это не маркетинг — это статистика из нашей практики.

Что входит в техподдержку 1С-Битрикс?

Регулярные работы (включены в абонент):

• Мониторинг: uptime + сценарии (корзина, заказ, обмен 1С)
• Бэкапы: pg_dump / mysqldump + rsync файлов → изолированное хранилище. Проверка восстанавливаемости
• Обновление ядра Битрикс и модулей: \Bitrix\Main\ModuleManager::isModuleInstalled() — проверка зависимостей, накат на staging, тестирование, деплой
• PHP и серверное ПО — обновление на выделенном сервере. Переход между мажорными версиями PHP — с проверкой deprecated-вызовов в кастомном коде
• Анализ /bitrix/admin/event_log.php и серверных логов — превентивное устранение ошибок
• SSL, домен — перевыпуск и продление
• Ежемесячный отчёт: что сделали, что нашли, что рекомендуем

Работы по запросу (из часового банка):

• Баги: «карточка товара не открывается на Safari» — диагностика, фикс, деплой
• Контент: баннеры, страницы, категории, товары
• Интеграции: новая платёжка, новая доставка, новый маркетплейс (Wildberries API, Ozon Seller API)
• Оптимизация: CIBlockElement::GetList с 20 JOIN тормозит → рефакторинг на D7 ORM с фасетным индексом
• SEO-доработки: мета-теги, Schema.org, sitemap
• Консультации: «Какой модуль Битрикса выбрать для рассрочки?»

Как мы обновляем ядро Битрикс?

Обновление — процесс не терпящий шаблонов. Сначала проверяем совместимость кастомных модулей с новой версией \Bitrix\Main\Application. Если в коде используются deprecated-методы — фиксим их до деплоя. Staging-окружение точная копия прода, включая настройки кэширования и очереди агентов. После тестов выкатываем, мониторим логи error_log и событий. При малейшем отклонении — откат за 5 минут. — Инструкция по обновлению ядра на dev.1c-bitrix.ru

Какие типичные задачи решаем в рамках техподдержки?

Контент. Баннеры к «Чёрной пятнице» — за день, потому что маркетолог вспомнил в четверг. Новая категория с фильтрами через catalog.smart.filter. Лендинг под рекламную кампанию — из готовых компонентов, без дизайнера, за 4-6 часов.

Функционал. Поле «прикрепить файл» в form.result.new — 2 часа. Форма записи на консультацию с интеграцией в AmoCRM через webhook — 4-6 часов. Подключение JivoSite / Carrot Quest — 1-2 часа.

Вёрстка. «Поехал» блок на iPhone с Dynamic Island — Safari рендерит env(safe-area-inset-top) по-своему. Обновили ядро Битрикс — сломался CSS карточки товара, потому что компонент catalog.element обновил HTML-структуру. Чиним.

Интеграции. Обмен с 1С: агент CAgent по catalog.import.1c упал по таймауту при 50 000 товаров — разбиваем импорт на пакеты через STEP. API СДЭК обновился с v1.1 на v2 — переписываем обработчик sale.delivery.handler. Новый эквайринг — настраиваем sale.paysystem.handler.

Серверные. Переход между мажорными версиями PHP: grep по deprecated (each(), create_function(), {$var} строковый доступ), фикс, тестирование. SSL: certbot не продлил — cron-задача не отрабатывала из-за смены пути к Python. DKIM/SPF/DMARC для почтового домена — чтобы уведомления о заказах не падали в спам.

Сроки и стоимость

Стоимость рассчитывается индивидуально под объём задач. Дополнительные часы по ставке из договора. Возможна смена пакета: повышение — в любой момент, понижение — с начала следующего месяца. Нестандартные требования обсуждаем отдельно. Свяжитесь с нами — подберём оптимальный вариант.

Экстренная поддержка — когда горит

Сайт лёг, оплата не проходит, обнаружен взлом.

• Горячая линия — Telegram + телефон. Для премиум-клиентов — выделенный номер дежурного инженера
• Реакция от 15 минут на критические инциденты
• Вне очереди — критичные инциденты обрабатываются раньше текущих задач, независимо от остатка часов
• Постмортем — после устранения фиксируем, что сломалось, почему и как предотвратить. Документируем в базе знаний проекта

Закажите техподдержку сейчас — получите первичный аудит в подарок и гарантию бесперебойной работы вашего проекта на 1С-Битрикс.