Моніторинг торгового бота: 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 тут лише частина картини: бот може бути живий за процесом і при цьому не торгувати, тому у схему закладаємо перевірки результату, а не лише наявності.

За підсумками обговорення повертаємося з переліком метрик, порогами, частотою опитування, маршрутом оповіщення та порядком ескалації. До схеми додаємо план робіт за етапами й оцінку строків за кожним пунктом.

Чогось зі списку може не бути — це з’ясується на розмові, і частину прогалин закривають наші інженери. Опишіть задачу, і повернемося з оцінкою та планом.