Мониторинг торгового бота: healthcheck, алерты, watchdog на продакшене

Почему мониторинг uptime торгового бота даёт сбои на продакшене

Мониторинг uptime обычно строится вокруг процесса: жив ли контейнер, отвечает ли порт, свежий ли файл лога. Это ловит падение целиком, но не отвечает на главный вопрос — торгует ли бот. Проверка доступности бота проходит зелёной, когда процесс работает, а торговый цикл стоит.

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

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

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

Причина системная: uptime измеряют по процессу, а не по бизнес-признакам — свежести сделок, времени ответа биржи, продвижению цикла. Внешние проверки по независимому каналу нужны потому, что сбой внутри процесса не может о себе сообщить: watchdog и алерты должны приходить извне. Дальше разбираем, как это закрывается.

Эффект от внедрения: реакция, простой и классы отказов

До внедрения мониторинга о сбое торгового бота узнавали постфактум — по пропущенным сигналам, расхождению позиций с биржей или ручной сверке. Обнаружение занимало от десятков минут до нескольких часов, и всё это время бот либо не торговал, либо держал открытые позиции без контроля. Сбор метрик, проверки живости и алерты на Prometheus переводят эту работу в измеримые величины, а не в «кажется, стало спокойнее».

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

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

Способы мониторинга uptime: внешний опрос, агент, анализ логов

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

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

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

Порядок внедрения: от аудита точек отказа до передачи

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

1. Аудит точек отказа. Составляем карту: торговое ядро, соединение с биржевыми интерфейсами, хранилище ордеров, канал оповещений. По каждому узлу фиксируем признак, по которому видно, что он перестал приносить результат.
2. Схема проверок. Решаем, что снимаем извне, а что изнутри процесса: доступность интерфейсов, расхождение локального состояния с биржевым, задержку обработки очереди и зависшие ордера.
3. Пороги оповещений. Настраиваем их на деградацию, а не только на падение: молчание при активном рынке, расхождение баланса сверх допуска, рост времени ответа. Порог срабатывает до того, как расхождение станет необратимым.
4. Учебный отказ. Искусственно обрываем связь и останавливаем часть сервисов, чтобы увидеть цепочку целиком. Убеждаемся, что сигнал доходит до дежурного инженера, а не оседает в логах.
5. Регламент реакции. Описываем, кому приходит оповещение, кто останавливает бота и что считается ложным срабатыванием. Без этого настроенная система приводит к спорам в момент аварии.
6. Передача в эксплуатацию. Отдаём панели со статусами, документацию по порогам и чек-лист под каждый тип оповещения, обучаем дежурную смену. Пороги пересматриваем вместе с вами: рынок и нагрузка меняются, а шум в оповещениях — главная причина, по которой мониторинг перестают читать.

Артефакты на выходе: конфигурации, схемы, регламенты

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

• Конфигурация проверок — декларативные файлы с адресами сервисов бота, интервалами опроса, пределами ожидания ответа и порогами деградации по каждому показателю. Новая проверка добавляется одной записью, без пересборки.
• Правила оповещений — маршрутизация по уровням: критичное поднимает дежурного, просадка уходит в рабочий канал. Отдельно описаны подавление дублей и группировка при массовом сбое, чтобы смена не тонула в сотне одинаковых сообщений.
• Схема связей сервисов — граф зависимостей от точки входа торговой логики до биржевого соединения, базы ордеров и очереди задач. На схеме помечены точки отказа и то, какие узлы деградируют вместе с каждым из них.
• Регламент дежурства — окна ответственности, время первого отклика по каждому уровню, порядок эскалации и критерии перевода бота в ручной режим торговли.
• Инструкция по диагностике — по каждому оповещению: что смотреть первым, где проверять состояние, как отличить сетевой сбой от ошибки в логике стратегии и что приложить к обращению.
• Правила сторожевого процесса — лимит автоматических перезапусков, пауза между ними и условие полной остановки при повторяющемся сбое, чтобы цикл рестартов не рубил открытые позиции.

Кейс: как убрали ночные простои торгового бота

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

Мы вынесли наружу признаки, по которым видно живость бота: регулярный heartbeat, свежесть последнего ответа биржевого API, расхождение между позицией в стратегии и фактическим счётом. Watchdog снимает процесс, переставший подавать признаки жизни, и поднимает его заново, а дежурный получает алерт с контекстом — что именно отвалилось и сколько это длится. Панель наблюдения на Grafana держит историю, поэтому разбор инцидента идёт по фактам, а не по рассказам.

Метрики до и после

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

Чем watchdog отличается от обычного алерта по метрике?

Алерт по порогу отвечает на вопрос «метрика вышла за границы нормы?» и передаёт решение человеку. Сторожевой механизм отвечает иначе — «что сделать прямо сейчас, чтобы бот остался в работе» — и выполняет это сам, не дожидаясь дежурного.

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

Сторожевой механизм — отдельный контур, который держит healthcheck снаружи торгового ядра. Он проверяет не только «процесс жив», но и признаки деградации: завис ли поток котировок, растёт ли время от сигнала до исполнения, отвечает ли узел сети. Живучесть в том, что контур не завязан на инфраструктуру бота — иначе падает вместе с ним.

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

Алерт информирует, сторожевой механизм удерживает uptime. В продакшене нужны оба: первый показывает, где слабое место в стратегии, второй закрывает окно, пока на смене никого нет.

Технические вопросы: ложные срабатывания, окна, доступы

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

Мониторинг uptime строится так, чтобы разделять «молчит, потому что ждёт сигнала» и «молчит, потому что упал». По отдельности ни heartbeat, ни задержки ответа биржи этого не показывают — только их совместная картина.

Что делать с уже развёрнутым ботом — его придётся перезапускать?

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

Нужен ли доступ к торговому счёту?

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

Как убрать ложные срабатывания?

Каждое правило проходит окно тишины: сигнал уходит, только если отклонение держится дольше заданного интервала. Всплеск задержки биржи или краткая просадка сети дежурного не будит.

Кто разбирает ночной алерт?

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

Обсудим задачу: соберём схему проверок и дадим план работ

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

• Как запущен бот: один экземпляр или несколько, есть ли резервный и как переключается трафик при отказе основного.
• Критичные сценарии: выставление и снятие заявок, поведение при отказах биржевого интерфейса, реакция на обрыв связи и на устаревшие данные котировок.
• Журналы и история сбоев за последние недели — по ним видно, какие проверки дадут сигнал раньше, чем заказчик заметит проблему.
• Куда и кому идёт оповещение: каналы, дежурные, ночное время, порог «будить или подождать».
• Требования к остановке: должен ли сторожевой процесс закрывать позиции сам или только уведомлять.
• Ограничения на доступ: что в продакшене можно читать, а что менять, и кто подтверждает изменения.
• Режим торговли: круглосуточно или сессиями — от этого зависит частота опроса и допустимое окно простоя.

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