Перейти к содержимому
BXWiki

Мониторинг интеграций - что проверять, пороги, оповещение

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

Что нужно знать заранее

Интеграция почти всегда ломается тихо и без единого сообщения. Обмен перестаёт приходить, уведомления отклоняются, а сайт при этом работает, и первым проблему замечает заказчик через день или два.

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

Оповещений от такого наблюдения должно приходить в команду заметно мало. Тревога на каждую мелочь приучает команду закрывать уведомления не читая, и настоящая авария теряется среди них.

Шаги

  1. Выбрать три-четыре метрики: время последнего обмена, поток заказов, размер очереди и ошибки.
  2. Снять их обычные значения за неделю и назначить пороги по факту.
  3. Написать проверку выбранных метрик и повесить её на регулярное задание по расписанию.
  4. Отправлять команде ежедневную сводку, а тревогу - только при нарушении порога.
  5. Пересматривать пороги после сезонных всплесков продаж и после каждого крупного релиза.

Решение

Смотрим время последнего обмена:

$last = (int)\Bitrix\Main\Config\Option::get('vendor.module', 'last_exchange_ts', 0);
$ageMinutes = (int)((time() - $last) / 60);
printf("последний обмен: %d минут назад\n", $ageMinutes);
// метку времени ставит сам обмен по завершении успешного шага

Метку времени ставит сам обмен, а не наблюдатель. Так проверка не зависит от разбора журналов и одинаково работает для любой интеграции проекта.

Считаем поток заказов за окно:

$cnt = \Bitrix\Sale\Internals\OrderTable::getCount([
    '>=DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-3 hours')]);
printf("заказов за три часа: %d\n", $cnt);
// ноль заказов в рабочее время при обычных двадцати - это авария, а не тишина

Смотрим очередь непереданных документов:

$stuck = \Bitrix\Sale\Internals\OrderTable::getCount([
    '=UPDATED_1C' => 'N', '<DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-1 day')]);
printf("не уехало в учётную систему: %d\n", $stuck);

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

Собираем проверку в задание:

$alerts = [];
if ($ageMinutes > 120) { $alerts[] = "обмена нет $ageMinutes минут"; }
if ($cnt === 0 && isWorkingHours()) { $alerts[] = 'нет заказов три часа'; }
if ($stuck > 20) { $alerts[] = "в очереди $stuck заказов"; }
if ($alerts) { notifyTeam(implode('; ', $alerts)); }

Отправляем сводку и тревогу:

function notifyTeam(string $text): void {
    (new \Bitrix\Main\Web\HttpClient(['socketTimeout' => 3, 'streamTimeout' => 5]))
        ->post(WEBHOOK_URL, ['text' => '[' . SITE_ID . '] ' . $text]);
}
// сводку шлют раз в сутки, тревогу - сразу и не чаще раза в час по одной причине

Повторную тревогу по той же причине гасят. Иначе сломавшийся ночью обмен к утру даёт двести одинаковых сообщений, и команда отключает уведомления совсем.

Типичные проблемы

О поломке обмена узнали от заказчика.

Наблюдение следило за ошибками, а обмен просто перестал приходить без единой ошибки. Отсутствие данных дольше порога считают такой же аварией, как и ошибку.

Команда перестала читать уведомления.

Тревога уходит на каждую мелочь и повторяется по одной и той же причине. Повторные тревоги по одной причине гасят, а мелкие замечания собирают в ежедневную сводку.

Ночная тишина каждый раз даёт ложную тревогу.

Порог по потоку заказов не учитывает ни время суток, ни выходные дни. Проверку потока заказов включают только в рабочие часы именно этого конкретного проекта.

Проверка сама падает и молчит вместе с обменом.

Задание наблюдения зависит от того же кода, за которым оно следит. Наблюдение делают максимально простым и полностью независимым от того механизма, за которым следит.

После релиза пороги стали срабатывать постоянно.

Изменился объём данных или расписание обменов, а пороги наблюдения остались прежними. Пороги наблюдения пересматривают после каждого релиза проекта и после сезонных всплесков продаж.

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

Какие метрики брать в первую очередь?

Время последнего успешного обмена и число новых заказов за окно. Эти две метрики ловят большинство поломок интеграции раньше всего.

Куда слать уведомления?

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

Как выбрать порог?

По фактическим значениям за неделю с запасом, а не по ощущениям. Порог, который срабатывает каждый день, бесполезен так же, как и отсутствующий.

Нужна ли внешняя система мониторинга?

Полезна, если она уже есть у проекта: тогда метрики отдают ей. Для одного магазина достаточно задания по расписанию и сообщений в чат.

Что делать с накопившейся очередью после починки?

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

Смежное

Первоисточник