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