Мониторинг криптобота: что ломается без наблюдения
Криптобот ломается тихо. Процесс остаётся в списке задач, соединение с биржей рвётся ещё ночью, ордера не выставляются — но нет ни падения, ни письма, ни звонка. О простое узнают по пустому экрану сделок и ручной сверке баланса спустя часы.
Основная причина сбоев бота — проглоченные ошибки биржевого интерфейса: код ответа проверяется не везде, исключение уходит в лог, файл растёт, читать его некому. Добавьте сюда ожидание ответа без таймаута и рассинхрон локального портфеля с реальными позициями — стратегия уверена, что всё работает, а заявки не уходят.
Цена простоя — не упавший сервис, а потерянные сделки: позиция без стопа, упущенный вход, принудительное закрытие на резком движении. Проверка раз в день такое не ловит, поэтому мониторинг криптобота строят на непрерывном сборе метрик и порогах, а не на ручном обходе.
Наблюдать нужно за периодическим сигналом жизни от стратегии, задержкой между сигналом и постановкой ордера, долей отказов биржи, временем ответа и расхождением баланса. Метрики собирает Prometheus, дашборды строим в Grafana, оповещения уходят дежурному при выходе за порог — диагностика зависаний занимает минуты вместо часов.
Разбираем, как это закрывается: какие метрики действительно предсказывают сбой, где ставить пороги и как отличить разовый отказ биржи от зависшего бота.
Что даёт наблюдаемость: эффект в измеримых величинах
Наблюдаемость криптобота — это не графики, а сокращение двух интервалов: времени до того, как мы узнали о сбое, и времени до того, как он перестал наносить ущерб. Сбор метрик бота покрывает задержку между сигналом стратегии и постановкой заявки, долю отклонённых биржей ордеров, глубину очереди и рассинхрон со стаканом, а дашборды Prometheus и Grafana сводят это в одну картину.
Время до обнаружения: минуты вместо часов
Правила алертов строятся на отклонении от базовой линии, а не на статичных порогах, поэтому всплеск волатильности не поднимает дежурного напрасно. Время реакции на инцидент падает с десятков минут — когда о поломке сообщал сам рынок — до одной-двух минут. Отдельные проверки ловят «тихие» отказы: процесс жив, но заявки перестали выставляться.
Дашборды: причина видна на схеме, а не в логах
Панели разложены по слоям — связь с биржей, стратегия, исполнение, состояние кошелька. Инженер на дежурстве видит не «бот не работает», а конкретный участок: разошёлся поток котировок, встал обработчик заявок или просела частота подтверждений. По той же схеме видно, когда метрика вернулась в норму, — восстановление подтверждается данными, а не словами.
Восстановление и доля инцидентов без последствий
Когда причина локализована по графику, достаточно откатить конфигурацию или перезапустить один узел, а не всего бота, — время восстановления укорачивается в разы. Расхождение позиций, зависшие ордера и потерянные сделки перестают доживать до момента, когда их замечает человек: их закрывают на этапе отклонения от нормы.
Способы организации мониторинга криптобота: что выбрать
Мониторинг криптобота закрывает две разные задачи: понимать, что процесс жив и торгует, и понимать, что он делает это правильно. Один источник данных не даёт обеих картинок, поэтому схемы наблюдения различаются не инструментами, а тем, какие отказы они вообще способны поймать.
Агент на том же сервере со сбором метрик через Prometheus даёт глубину: задержка обработки сигнала, длина очереди ордеров, состояние соединения с биржей. Внешние проверки доступности отвечают на вопрос «жив ли бот» с независимой точки, разбор логов — на вопрос «почему не сработало». Ниже — сравнение по слепым зонам.
| Схема наблюдения | Когда подходит | Слепая зона |
|---|---|---|
| Агент на том же сервере | Нужны метрики процесса: задержка обработки, очередь ордеров, состояние соединения с биржей | Падение сервера или сети — метрики перестают поступать вместе с ботом, и уведомление не приходит |
| Внешние проверки доступности | Нужна независимая точка, подтверждающая, что бот отвечает и принимает команды | Видит факт доступности, но не отличает работающего бота от зависшего в ожидании |
| Разбор логов | Разбор причин: на каком шаге отказ, почему не выставлен ордер | Проблема фиксируется постфактум, окно между сбоем и реакцией растягивается |
| Гибридная схема | Постоянно работающий бот с реальными сделками | Требует поддержки: пороги и правила уведомлений пересматривают после каждой правки стратегии |
Гибрид — рабочая схема для боевого бота: агент собирает внутренние метрики, внешний пробник проверяет доступность снаружи, логи агрегируются отдельно. Совпадение двух сигналов отсекает ложные срабатывания, поэтому уведомления приходят по делу, а окно между сбоем и реакцией сокращается с часов до минут.
Порядок внедрения: от аудита до передачи регламентов
Внедрение начинается не с развёртывания сборщика, а с плана внедрения мониторинга: что уже работает в контуре, какие сбои критичны и как быстро команда должна о них узнавать. Без этого дашборды рисуют красивые графики, но не отвечают на главный вопрос — почему бот перестал исполнять ордера и в какой момент это началось.
- Инвентаризация узлов. Составляем карту контура: RPC-ноды, сервис подписи, очереди заданий, воркеры стратегий, хранилища. По каждому узлу фиксируем владельца, режим работы и зависимости — на этой карте строится вся схема наблюдения.
- Схема наблюдения. Разделяем, что снимаем с приложения, а что с инфраструктуры: задержку ответа ноды, число подтверждённых транзакций, разрыв между сигналом и исполнением, состояние ключей и лимитов.
- Настройка сборщика. Разворачиваем сбор и хранение метрик на Prometheus и Grafana, задаём интервалы съёма и срок хранения, чтобы объём данных не рос бесконтрольно. Дашборды собираем по ролям: дежурный, разработчик, руководитель.
- Пороги срабатывания. Пороги считаем от собственной статистики бота, а не «на глаз»: уровень предупреждения и критичный. Так дежурного не будит нормальный всплеск активности сети.
- Проверка алертов. Прогоняем на живых сбоях: гасим узел, тормозим очередь, отзываем доступ. Смотрим, кто получил сигнал, за какое время и не потерялся ли он в шуме.
- Передача наблюдения. Регламенты дежурств, каналы оповещений, инструкции по типовым сбоям, роли и доступы, обучение команды.
Комплект передачи: конфигурации, схемы, регламенты дежурства
Мониторинг криптобота переживает разработчика только в одном случае — если он передан как работающая система, а не как набор дашбордов на чужом аккаунте. Поэтому в комплект передачи входят не только панели, но и то, чем их воспроизводят, дежурят и разбирают сбои.
- Файлы конфигурации — экспортёры, job-описания, дашборды и правила алертов лежат в системе контроля версий с осмысленной историей изменений. Развёртывание стенда мониторинга повторяется из репозитория, без ручных правок на сервере.
- Схема узлов бота — какие процессы, на каких узлах, что с чем обменивается данными, где точки отказа: обрыв связи с биржей, отставание очереди ордеров, недоступность базы истории сделок.
- Правила алертов — по каждому сигналу зафиксированы порог, окно усреднения, приоритет и адресат. Отделены «горит сейчас» от «посмотреть утром» — иначе дежурный перестаёт реагировать на уведомления.
- Инструкция дежурного — порядок действий от срабатывания до эскалации: что проверить, какие команды безопасны, когда останавливать торговую логику, кого поднимать и по какому каналу.
- Регламент разбора инцидента — сроки фиксации, обязательные поля разбора (симптом, корневая причина, действие), критерий, при котором правило алерта переписывают, а не глушат.
- Доступы и роли — отдельные учётные записи для дежурного и для администратора, порядок выдачи и отзыва, чтобы уход человека не оставлял систему без присмотра.
Передача заканчивается приёмкой: инженер заказчика сам поднимает стенд из репозитория, проводит тренировочное срабатывание и проходит разбор по инструкции. Если на этом шаге что-то не воспроизводится — комплект дополняем, пока не воспроизведётся.
Кейс: сбои бота находили по жалобам, теперь — за минуты
Контур до: логи есть, наблюдения нет
Бот торговал на двух биржах и складывал логи в файлы на сервере. Формально данные для разбора были — фактически их никто не открывал: пороги не считались, снимков состояния не сохранялось. Первый серьёзный сбой выглядел так: одна нога сделки исполнилась, вторая нет, позиция осталась висеть открытой на несколько часов.
О проблеме команда узнала от клиента на следующее утро. Разбор инцидента по логам занял почти четыре часа: нужно было вручную сопоставить записи приложения, ответы биржи и историю ордеров. Кейс мониторинга бота начался именно с этого — не с желания «сделать красивые графики», а с необходимости понять, что произошло, без археологии.
Что изменили
Приложение теперь отдаёт метрики по каждой ноге сделки: число открытых и зависших ордеров, задержку ответа биржи, расхождение баланса с расчётным, глубину очереди задач. Сбор идёт через Prometheus, дашборд собирается в Grafana, алерты разведены по критичности — расхождение баланса и зависший ордер зовут дежурного немедленно, рост задержки приходит предупреждением.
Метрики до и после
- время обнаружения сбоя: было 3-6 часов (по жалобе клиента), стало 30-90 секунд — по алерту на метрику;
- разбор инцидента: было 2-4 часа ручного сопоставления логов, стало 10-20 минут: дашборд показывает состояние счёта и ордеров на момент сбоя;
- зависшие позиции: закрываются автоматически по правилу, дежурный проверяет только факт закрытия;
- доля сбоев, найденных до обращения клиента: девять из десяти.
Каждый инцидент теперь сохраняется со снимком метрик за час до и после — следующий разбор начинается с готовой картины, а не с нуля.
Чем внешняя проверка доступности отличается от сбора метрик?
Внешняя проверка доступности — это чёрный ящик: независимый пробник с отдельного контура раз в несколько секунд дёргает точку проверки бота и торговый API, замеряя время ответа. По сути это сигнал живости, который не зависит от того, что процесс думает о себе сам.
Сбор метрик работает изнутри: бот публикует счётчики и задержки — долю отклонённых биржей заявок, лаг обработки стакана, глубину очереди задач, расхождение локальной позиции с биржевой. Такой контур видит деградацию задолго до отказа, но именно поэтому его нельзя считать достаточным.
Главное слепое пятно внутренних метрик — момент, когда процесс завис или упал: цифры просто перестают поступать, и это молчание легко спутать со стабильностью. Внешний пробник, наоборот, ловит зависание цикла обработки, отвал соединения с биржей, исчерпание пула, ошибку на границе сети — но не объясняет причину.
Разница подходов в том, что каждый видит своё. Проверка снаружи отвечает, работает ли сервис прямо сейчас, а сбор метрик — почему он стал работать медленнее и куда движется тренд: растёт лаг выставления заявок, падает доля исполненных, расходится баланс.
Поэтому одного подхода недостаточно: внешние проверки без метрик дают тревогу без диагноза, метрики без пробника молчат именно в момент поломки. Мы настраиваем оба контура в общей системе оповещения, с разными порогами и окнами усреднения, чтобы сигнал приходил и на отказ, и на медленную деградацию.
Технические сомнения: перегрузка, доступы, ложные алерты
Перед согласованием наблюдения инженеры задают одни и те же вопросы: не съест ли оно ресурсы, кому отдаём доступы, не утонем ли в шуме. Разбираем каждый пункт.
Не начнёт ли мониторинг конкурировать с торговой логикой?
Метрики отдаёт отдельный эндпоинт вне цикла обработки ордеров: сбор идёт по интервалу, а не по каждому событию, поэтому нагрузка растёт не линейно. На тестовом контуре снимаем профиль до и после включения наблюдения и фиксируем расхождение в отчёте.
Придётся ли отдавать приватные ключи или доступ к бирже?
Нет. Наблюдение читает метрики и логи через эндпоинт только на чтение. Приватные ключи подписи не покидают защищённый контур и не попадают ни в конфигурацию сборщика, ни на дашборды. Для контроля баланса заводим отдельный ключ с запретом на вывод.
Как настроить пороги, чтобы не тонуть в ложных алертах?
Пороги задаём не «на глаз»: сначала собираем статистику обычного поведения, затем ставим границы по перцентилям с окном усреднения. Срабатывания группируются и дедуплицируются, повторяющиеся гасятся — шум не смешивается с критичным сигналом. У каждого алерта есть привязанное действие, а не «посмотреть».
Что с дежурством в нерабочие часы?
Уровни эскалации разделены: предупреждения уходят в рабочий канал и разбираются утром, критичные поднимают дежурного. Для типовых отказов — зависший обработчик, разрыв соединения — настраиваем авто-восстановление, и ночью человека не будят. На нестандартные случаи есть инструкция: что проверить, как откатить, кого подключить.
Обсудим задачу: как построить наблюдение под ваш контур
Разговор начинаем с контура: какие биржи и стратегии обслуживает бот, где он запущен, кто и как узнаёт о сбое сегодня — вручную по логам или по оповещению. По итогам вернёмся с оценкой и планом работ, где будет видно, какие метрики снимаем, где ставим пороги и кто получает сигнал. Старт наблюдения за ботом обычно занимает меньше времени, чем кажется, если заранее собрать вводные.
Что нужно от вас, чтобы оценка была точной:
- доступы к узлам, где работает бот, в режиме только чтение — к сервису, конфигурациям и хранилищу логов;
- перечень процессов, за которыми следим: выставление и отмена ордеров, синхронизация с биржей, пополнение баланса, зависшие задачи;
- список сбоев, которые уже случались, и ваша градация критичности — по ним расставим приоритеты оповещений;
- каналы доставки сигналов: мессенджер, почта, звонок, и кому именно они адресованы в разное время суток;
- окна обслуживания и допустимое время простоя, чтобы дежурный не просыпался от плановых работ;
- требования к истории: сколько хранить метрики и как часто делать срезы для разбора инцидентов.
На выходе вы получаете карту метрик с описанием смысла каждой, конфигурацию сбора, панели графиков по ключевым узлам, правила оповещений с порогами и защитой от дребезга, а также короткую инструкцию для дежурного: что смотреть в первую очередь и какие действия безопасны. Отдельно проверим схему на учебном сбое — остановим обработчик и убедимся, что сигнал дошёл до нужного человека.
Опишите задачу — вернёмся с оценкой и планом.
