Мониторинг обязательных интеграций: узнать о сбое раньше контрагента

MAATRIX

Если ваш бизнес обязан передавать данные во внешнюю систему — коды маркировки в «Честный знак», чеки через ОФД, движения алкоголя в ЕГАИС — регулятор узнаёт о сбое интеграции точно так же, как и вы: по факту остановки потока данных. Разница в том, кто узнаёт первым. Если первым узнаёте не вы, а система на другой стороне, счёт идёт не на часы простоя, а на штраф или блокировку деятельности, о которой вы услышите постфактум. Разберём, как поставить мониторинг так, чтобы разрыв интеграции обнаруживал не регулятор, а ваш телефон — за минуты, а не за дни.

Почему тут нужен именно проактивный мониторинг

С обычным сервисом логика простая: сайт упал — клиенты не могут купить — вы теряете деньги здесь и сейчас, и обратная связь приходит быстро сама по себе (жалобы, падение конверсии). С обязательными интеграциями обратная связь работает иначе и гораздо медленнее.

Возьмём типичный сценарий с маркировкой. Касса продолжает пробивать чеки, товар физически продаётся, покупатель ничего не замечает — а коды выбытия при этом не уходят в «Честный знак», потому что сервис-агент на сервере интеграции упал три дня назад после обновления. Бизнес-процесс снаружи выглядит абсолютно здоровым. Проблема не создаёт очевидного симптома, который заметит кто-то не из IT — она копится тихо, как заряд, до момента проверки или автоматического выявления расхождения на стороне оператора системы.

Дальше начинает работать разница в постановке штрафа. У обычного простоя есть один пострадавший — вы. У сорванной обязательной интеграции есть регулятор, для которого факт непередачи данных — это отдельное, самостоятельное нарушение, зафиксированное автоматически, вне зависимости от того, знали вы о нём или нет. Незнание не освобождает от ответственности, а к моменту, когда вам придёт уведомление о нарушении, счётчик уже может тикать не первый день:

• по 54-ФЗ несвоевременная передача фискальных данных через ОФД — основание для административного штрафа, а накопленный на кассе объём неотправленных документов сверх срока хранения фискального накопителя технически блокирует саму возможность пробивать чеки;
• по системе маркировки «Честный знак» продажа немаркированного или не выбывшего в системе товара образует отдельный состав нарушения — независимо от того, был ли товар маркирован физически, если сведения не дошли до оператора;
• по ЕГАИС остановка передачи данных о движении алкогольной продукции при определённых условиях технически блокирует саму отгрузку — касса или система учёта просто не даст провести операцию без подтверждения от сервера ЕГАИС.

Общий принцип везде один: у вас есть некоторое окно, в течение которого можно накапливать неотправленные данные без последствий (у кассы — срок хранения в фискальном накопителе, у маркировки и ЕГАИС — таймауты синхронизации), и это окно конечно. Если вы узнаёте о сбое, когда окно уже закрылось, у вас нет времени на реакцию — есть только объяснительная. Если узнаёте в первые минуты — есть весь запас окна, чтобы решить проблему без последствий. Разница между «через минуту после падения» и «когда позвонит бухгалтер, у которой не сошлась отчётность» — это и есть вся ценность проактивного мониторинга здесь.

Такие сбои почти никогда не выглядят как классическая авария с полным отказом. Гораздо чаще это тихая деградация — сертификат истёк, токен авторизации отозван, очередь растёт, потому что обработчик завис, но не упал (значит, systemd его не перезапустит). Мониторинг «жив ли процесс» тут не спасает: процесс жив, просто ничего не делает.

Что именно имеет смысл мониторить

Для любой обязательной интеграции — маркировка, ОФД, ЕГАИС, ЭДО и подобные — набор точек контроля почти одинаковый, потому что схема взаимодействия у них одна и та же: локальный агент/касса → сервер интеграции → канал связи → внешняя система оператора.

1. Доступность канала связи с внешней системой. Не «пингуется ли интернет вообще», а именно достижимость конкретного эндпоинта интеграции — по нужному порту и протоколу, с интервалом в одну-две минуты. Пример синтетической проверки TCP-порта:

#!/bin/bash
# check_endpoint.sh — проверка доступности эндпоинта интеграции
HOST="edo.crpt.ru"
PORT=443
TIMEOUT=5

if ! timeout $TIMEOUT bash -c "cat < /dev/null > /dev/tcp/$HOST/$PORT" 2>/dev/null; then
  echo "CRITICAL: $HOST:$PORT недоступен"
  exit 2
fi
echo "OK: $HOST:$PORT доступен"
exit 0

Такой скрипт можно завернуть в проверку Uptime Kuma (тип "TCP Port"), в Zabbix через UserParameter, или в отдельный cron с отправкой в healthchecks.io. Важно проверять не только сетевую доступность, но и то, что сертификат на другой стороне валиден и рукопожатие TLS проходит — иначе можно получить ложное "OK" при сломанном TLS-стеке.

2. Наличие и рост очереди необработанных документов/событий. Это самая недооценённая точка контроля — и одновременно самая важная. Канал может быть полностью доступен, процесс — жив и отвечать на пинг, а очередь на отправку — расти, потому что обработчик завис на конкретном сообщении, исчерпал лимит запросов у оператора или получает ошибки авторизации на каждой попытке. Практическая метрика — количество необработанных документов в очереди и время, которое самый старый из них там лежит:

#!/bin/bash
# check_queue.sh — проверка очереди сервиса интеграции с ОФД/маркировкой
QUEUE_DIR="/var/lib/integration-agent/queue"
MAX_AGE_MIN=30
MAX_COUNT=200

count=$(find "$QUEUE_DIR" -type f -name "*.json" | wc -l)
oldest_age=$(find "$QUEUE_DIR" -type f -name "*.json" -printf '%T@\n' 2>/dev/null | sort -n | head -1)

if [ -n "$oldest_age" ]; then
  now=$(date +%s)
  age_min=$(( (now - ${oldest_age%.*}) / 60 ))
else
  age_min=0
fi

if [ "$count" -gt "$MAX_COUNT" ] || [ "$age_min" -gt "$MAX_AGE_MIN" ]; then
  echo "CRITICAL: очередь $count документов, самый старый $age_min мин"
  exit 2
fi
echo "OK: очередь $count документов, самый старый $age_min мин"
exit 0

Точный путь к очереди и формат зависят от конкретного агента (у УТМ для ЕГАИС, у сервис-агентов маркировки, у ОФД-модулей путь и формат разные — сверяйтесь с документацией вашего ПО), но принцип переносится один в один: считать количество и возраст, а не факт "процесс запущен". Пороги (200 документов, 30 минут) — ориентир, отталкивайтесь от вашего реального потока документов и от того, сколько времени у вас есть до жёсткого лимита конкретной системы.

3. Срок действия сертификатов интеграции. У ОФД, ЕГАИС и «Честного знака» взаимодействие защищено сертификатами — либо ГОСТ-сертификатом для УТМ ЕГАИС, либо обычным TLS/клиентским сертификатом для API-интеграции с ОФД или ЭДО. Истечение сертификата останавливает передачу так же надёжно, как физический обрыв канала, но происходит предсказуемо — у сертификата есть точная дата, и это единственная причина сбоя из всех перечисленных, которую можно предотвратить заранее стопроцентно.

#!/bin/bash
# check_cert_expiry.sh — дней до истечения сертификата интеграции
CERT_PATH="/etc/integration-agent/client.crt"
WARN_DAYS=14

expiry_date=$(openssl x509 -enddate -noout -in "$CERT_PATH" | cut -d= -f2)
expiry_epoch=$(date -d "$expiry_date" +%s)
now_epoch=$(date +%s)
days_left=$(( (expiry_epoch - now_epoch) / 86400 ))

if [ "$days_left" -le "$WARN_DAYS" ]; then
  echo "WARNING: сертификат истекает через $days_left дней ($expiry_date)"
  exit 1
fi
echo "OK: сертификат действителен ещё $days_left дней"
exit 0

Для сертификатов ГОСТ, которые openssl не всегда умеет разбирать напрямую, аналогичную проверку часто удобнее делать через утилиты из комплекта СКЗИ (КриптоПро CSP и подобные), либо вести отдельный календарь сроков действия с запасом в 30 дней на переоформление — процедура получения нового ГОСТ-сертификата не мгновенная и может потребовать личного визита или почтовой пересылки.

4. Синхронизация времени на сервере. Отдельный пункт, который редко упоминают, но который ломает сразу несколько вещей одновременно: расхождение системных часов больше чем на несколько секунд может приводить к отказу проверки подписи или TLS-рукопожатия на стороне оператора. Проверка через chronyc или ntpstat с интервалом в несколько минут и алертом при отклонении — дешёвая страховка от нетривиального в диагностике сбоя.

Практическая настройка алертов: куда должно прийти уведомление

Мониторинг, который никто не видит вовремя, эквивалентен его отсутствию — с той разницей, что создаёт ложное чувство защищённости. Смотрите статью про частые причины, почему уведомления в Telegram не доходят или их не замечают — большинство этих причин применимо к любой системе алертинга, не только к Uptime Kuma.

Практический набор требований к каналу уведомления для обязательной интеграции:

Последний пункт — не паранойя, а частый реальный сценарий: если Uptime Kuma или Zabbix стоят на том же сервере, что и сама интеграция, падение сервера убивает и объект мониторинга, и сам мониторинг одновременно — алертов не будет вообще. Разносите мониторинг физически: отдельный недорогой VPS в другом дата-центре плюс внешний heartbeat-сервис вроде healthchecks.io, которому ваш сервер обязан "отмечаться" каждые N минут — если отметка не пришла, сервис сам поднимает тревогу независимо от состояния вашего сервера.

Пример простого heartbeat-скрипта, который совмещает проверку очереди и сертификата с отметкой во внешнем сервисе:

#!/bin/bash
# heartbeat.sh — раз в 5 минут через cron
HC_URL="https://hc-ping.com/ваш-uuid-проверки"

/usr/local/bin/check_endpoint.sh && \
/usr/local/bin/check_queue.sh && \
/usr/local/bin/check_cert_expiry.sh

if [ $? -eq 0 ]; then
  curl -fsS -m 10 "$HC_URL" > /dev/null
else
  curl -fsS -m 10 "$HC_URL/fail" > /dev/null
fi

Логика простая: если все внутренние проверки прошли — сервер "отмечается" во внешнем сервисе как живой. Если хотя бы одна упала, отправляется явный сигнал /fail, и healthchecks.io присылает алерт немедленно. Если сервер вообще не вышел на связь (упал целиком, потерял сеть) — healthchecks.io заметит отсутствие отметки по таймауту и тоже пришлёт алерт, независимо от того, что происходит на вашей стороне. Это закрывает и сценарий "всё сломалось тихо", и сценарий "сломалось всё, включая мониторинг".

Пороги и частота проверок: не переборщить и не прозевать

Слишком частые проверки с низким порогом дают усталость от алертов — их начинают игнорировать, и тогда действительно критичное уведомление тонет среди шума. Слишком редкие или мягкие пороги оставляют слепую зону, за время которой очередь успевает вырасти до критичной. Разумные ориентиры, которые стоит адаптировать под ваш реальный поток документов, а не копировать бездумно:

• проверка доступности канала — раз в 1-2 минуты, алерт при 2-3 подряд неудачных попытках (чтобы не реагировать на единичный сетевой моргание);
• проверка очереди — раз в 5 минут, WARNING при превышении обычного объёма в 2-3 раза, CRITICAL при приближении к лимиту, за которым система блокирует операции;
• проверка сертификатов — раз в сутки достаточно, но с несколькими порогами предупреждения: за 30, за 14 и за 3 дня до истечения, с нарастающей настойчивостью алерта;
• проверка синхронизации времени — раз в 5-10 минут, алерт при расхождении больше нескольких секунд.

Конкретные цифры очереди и лимиты по времени храните до блокировки зависят от вашей системы, объёма документооборота и конкретного ПО-агента — это стоит один раз выяснить у поставщика вашего сервис-агента или в его документации и зафиксировать во внутреннем регламенте, а не полагаться на память дежурного инженера в момент инцидента.

Где физически размещать сервер интеграции и мониторинг

Для интеграций, через которые проходят фискальные и персональные данные (ОФД, ЕГАИС), сервер интеграции по требованиям законодательства должен находиться в российском юрисдикционном контуре. Мониторинг такого сервера логично строить в том же контуре, но с отдельным, физически независимым узлом — если основной сервер и узел мониторинга стоят у одного провайдера в одной стойке, вы получаете частичную защиту: локальный сбой электропитания или сети дата-центра положит оба узла одновременно.

Практичная схема — вынести узел мониторинга на отдельный небольшой VPS, а внешний heartbeat-сервис вроде healthchecks.io использовать как третий, полностью независимый уровень контроля. Подробнее о серверной части интеграции с маркировкой и о том, на что там смотреть в первую очередь, — в статье «Честный знак: серверная часть интеграции и где она обычно падает», а нюансы портов и типичных затыков УТМ для ЕГАИС — в статье «ЕГАИС и УТМ на своём сервере: порты и затыки». Инфраструктурная сторона мониторинга кассы и ОФД разобрана в статье «ОФД и касса: что должно работать на сервере, чтобы чеки уходили» — там же пример полного набора проверок для этого конкретного случая.

Частые вопросы