Обмен без мониторинга — чёрный ящик: пока не позвонит клиент с вопросом «где мой заказ», никто не знает, что очередь встала два часа назад. Разберём, какие метрики очередей обмена отслеживать в 1С-Битрикс и как выстроить оповещения о проблемах.
Зачем мониторить очереди обмена
Когда обмен переходит из синхронного в очередной (задания копятся и обрабатываются фоном), появляется новый риск — тихое накопление. Очередь растёт, задания застревают, а внешне сайт работает. Проблема всплывает с задержкой и уже как жалоба клиента.
Мониторинг очередей решает три задачи:
- Раннее обнаружение — узнать о заторе до того, как он станет заметен покупателю.
- Диагностика — понять, какой обмен и на каком этапе встал.
- Контроль SLA — гарантировать, что заказ доходит до CRM и склада за оговорённое время.
Ключевые метрики очереди
Полезно отслеживать небольшой, но правильный набор метрик. Их источник — собственная таблица заданий обмена с полями статуса, попыток и меток времени.
| Метрика | Что показывает | Тревожно, когда |
|---|---|---|
| Глубина очереди | Число заданий в ожидании | Растёт и не убывает |
| Лаг (возраст) | Время самого старого задания | Превышает SLA |
| Пропускная способность | Заданий в минуту | Резко упала |
| Доля ошибок | failed / всего | Растёт выше нормы |
| Размер карантина | Заданий в dead letter | Ненулевой и растёт |
Самая важная метрика — лаг очереди (возраст старейшего необработанного задания). Именно он напрямую отвечает на вопрос «насколько сайт отстаёт от учёта прямо сейчас».
Лаг очереди и SLA обмена
Глубина очереди обманчива: 1000 лёгких заданий обработаются за минуту, а 10 тяжёлых могут висеть полчаса. Поэтому целевой показатель формулируют через лаг и привязывают к SLA.
- Остатки: лаг не более 15 минут.
- Заказы сайт → CRM: лаг не более 2–3 минут.
- Каталог и цены: лаг до часа допустим.
Для каждого типа обмена — свой порог. Лаг считают как разницу между «сейчас» и меткой создания старейшего задания в статусе ожидания: NOW() - MIN(created_at) WHERE status = 'pending'. Превышение порога — сигнал, что обработчик не справляется или встал.
Health-check и живость обработчика
Отдельная проблема — «тихая смерть» обработчика: агент или воркер упал, задания копятся, но никто их не берёт. Метрики очереди это покажут не сразу, поэтому нужен прямой контроль живости.
- Heartbeat. Обработчик пишет метку времени последнего запуска; если она устарела — воркер мёртв.
- Health-check endpoint. Отдельный URL, отдающий статус очереди для внешнего мониторинга (например, аптайм-сервиса).
- Контроль cron/агентов. Проверка, что регулярные задачи 1С-Битрикс реально запускаются.
В 1С-Битрикс агенты на хите ненадёжны под фоновый обмен — при низком трафике они просто не вызываются. Для стабильной обработки очереди используют системный cron через cron_events.php, а heartbeat подтверждает, что он действительно отработал.
Дашборды и оповещения
Метрики нужно куда-то выводить и на что-то реагировать. Уровень инструментария подбирают под масштаб.
- Простой уровень — служебная страница в админке 1С-Битрикс с таблицей: глубина, лаг, ошибки, размер карантина по каждому обмену.
- Средний — выгрузка метрик во внешний сервис (Zabbix, Prometheus + Grafana) с историей и графиками.
- Алерты — уведомления в Telegram или почту при пробое порога лага, росте ошибок или ненулевом карантине.
Правильный алерт конкретен и действенен: не «что-то сломалось», а «очередь остатков: лаг 42 мин, порог 15, глубина 3200, обработчик молчит 20 мин». По такому сообщению сразу понятно, куда бежать.
Реакция на инциденты
Мониторинг ценен только если за алертом следует понятное действие. Типовые сценарии стоит описать заранее.
- Лаг растёт, ошибок нет — обработчик не справляется по скорости: увеличить частоту запуска или число воркеров, разбить обмен на батчи.
- Растёт доля ошибок — проблема на стороне внешнего API или данных: смотреть лог, при фатальной ошибке ставить обмен на паузу.
- Обработчик молчит — упал воркер или не запускается cron: перезапустить, проверить heartbeat.
- Растёт карантин — накапливаются битые данные: разобрать причину, исправить источник, переотправить задания.
Хорошая практика — держать ручку паузы обмена. При инциденте на внешней системе лучше остановить очередь, чем гнать в неё заведомо провальные запросы и раздувать карантин.
Итог
Мониторинг очередей обмена превращает связку из чёрного ящика в управляемую систему. Отслеживают глубину, лаг, пропускную способность, долю ошибок и размер карантина, привязывают пороги к SLA по типам обмена, контролируют живость обработчика через heartbeat и настраивают конкретные, дедуплицированные алерты с понятным сценарием реакции.
Мы в B2Bsite встраиваем мониторинг в обмен на этапе разработки: собственные метрики и дашборд, health-check, алерты в мессенджер и ручку паузы. Если ваш обмен периодически встаёт, а узнаёте вы об этом от клиентов, — сделаем его состояние прозрачным и предсказуемым.
Частые вопросы
Какая метрика очереди самая важная?
Лаг — возраст самого старого необработанного задания. Он напрямую показывает, насколько сайт отстаёт от учёта прямо сейчас, тогда как глубина очереди без учёта тяжести заданий обманчива.
Чем плоха глубина очереди как единственная метрика?
Тысяча лёгких заданий обработается за минуту, а десять тяжёлых могут висеть полчаса. Поэтому целевой показатель формулируют через лаг и привязывают к SLA, а глубину смотрят как дополнение.
Как понять, что обработчик очереди умер?
По heartbeat: обработчик пишет метку времени последнего запуска, и если она устарела при непустой очереди — воркер не работает. Метрики глубины покажут это не сразу, поэтому нужен прямой контроль живости.
Почему нельзя держать обмен только на агентах Битрикса?
Агенты на хите вызываются только при заходах на сайт и при низком трафике могут не запускаться. Для стабильной фоновой обработки очереди используют системный cron через cron_events.php.
Куда выводить метрики обмена?
На простом уровне — служебная страница в админке с таблицей метрик по каждому обмену. При росте нагрузки метрики выгружают во внешний мониторинг вроде Zabbix или Prometheus с Grafana для истории и графиков.
Каким должен быть полезный алерт?
Конкретным и действенным: с названием обмена, текущим и пороговым лагом, глубиной очереди и состоянием обработчика. По такому сообщению сразу понятно, что и где сломалось.
Что делать, если лаг растёт, а ошибок нет?
Значит обработчик не справляется по скорости. Помогает увеличение частоты запуска или числа воркеров, разбиение обмена на батчи и вынос тяжёлых операций в отдельную очередь.
Поможем с настройкой и поддержкой Интеграции и связки систем
Поможем с настройкой, доработкой и поддержкой Интеграции и связки систем.