Чому логування криптобота розсипається на першому ж збої
Бот надсилає заявку, біржа не відповідає довше заданого інтервалу, позиція залишається відкритою — а в журналі один рядок про помилку з'єднання. Далі починається реконструкція за непрямими ознаками: звірка балансів, вивантаження з особистого кабінету, зіставлення часу подій.
На таку діагностику збою йдуть години, і вона все одно не відповідає на головне питання — була угода чи лише спроба.
Причина в тому, що події пишуться не наскрізним потоком, а частинами: сигнал стратегії — в одному місці, відповідь виконання — у другому, стан позиції — у третьому. Коли один із учасників падає, сусідні записи втрачають зв'язок, і втрата угод перестає бути перевірним фактом.
Логування криптобота в такому вигляді фіксує факт падіння, але не ланцюжок рішень, який до нього призвів, тому кожен збій торгового бота доводиться пояснювати заново.
Окреме вузьке місце звітності — формат запису. Вільний текст зручний людині, але не піддається групуванню: не можна порахувати частку відхилених заявок, час від сигналу до підтвердження, частоту повторів за одним інструментом.
Поки ці величини не виводяться з журналу, суперечка про те, чи винен ринок, чи логіка бота, залишається суперечкою про смаки.
Довіра до стратегії тримається на відтворюваності: за журналом угода має збиратися від сигналу до закриття позиції — з ідентифікатором заявки, міткою часу та версією конфігурації. Нижче розбираємо, як це закривається.
Що змінюється після впровадження: розбір збою та повнота історії
До налаштування логування збій у боті виглядав так: ордер пішов на біржу, відповідь не розібралася, позиція залишилася відкритою, а в логах — один рядок без ідентифікатора.
Розбір такого випадку займав години: доводилося звіряти вивантаження з біржі, баланс гаманця та листування в месенджері, щоб відновити порядок подій.
Ми переводимо логування на подієву модель. Кожна дія — розрахунок сигналу, виставлення ордера, підтвердження, часткове виконання, скасування, перерахунок позиції — пишеться окремим записом з наскрізним ідентифікатором кореляції, міткою часу та знімком вхідних параметрів. Записи потрапляють у незмінний журнал, поверх якого будується звітність за угодами.
Повнота історії угод перестає залежати від того, чи встиг бот дописати файл до перезапуску: запис підтверджується до переходу до наступного кроку, тому пропусків в історії не залишається.
Час розбору інциденту падає з годин до хвилин — за ідентифікатором піднімається весь ланцюжок від сигналу до виконання, включно з відповідями біржі та перевищеннями часу очікування.
Відтворюваність стану дає програвання журналу в тестовому контурі: поведінка бота на історичних даних повторюється крок за кроком.
Це прибирає цілий клас відмов — втрату стану після рестарту, дублі ордерів і «завислі» позиції, які раніше знаходили тільки за розходженням балансу, — і напряму підвищує стійкість бота. Панель моніторингу в Grafana показує розходження в реальному часі, а не постфактум.
Режими запису: повний потік, вибірка подій, тільки помилки
Режим запису визначає, що взагалі вдасться відновити під час розбору інциденту. Повний потік зберігає кожну подію — заявки, відповіді біржі, зміни балансу та стану, тому обсяг сховища зростає лінійно з активністю бота.
Запис тільки помилок дає мінімальний слід: виключення видно, а ланцюжка рішень, який до нього призвів, — вже ні.
| Режим | Що фіксується | Коли підходить | Сліпі зони | Обсяг сховища |
|---|---|---|---|---|
| Повний потік | Усі події циклу та відповіді зовнішніх систем | Налагодження нової стратегії, розбір складних збоїв | Практично немає | Зростає лінійно з кількістю заявок |
| Відбір подій | Заявки, угоди, відмови, зміна стану бота | Постійна робота в проді | Проміжні кроки розрахунку | Передбачуваний, задається правилами відбору |
| Тільки помилки | Виключення та неуспішні відповіді | Мінімальне спостереження за ботом | Причина збою лежить поза записом | Фіксований мінімум |
На практиці режими не вибирають по одному: повний потік вмикають на короткому вікні навколо релізу або інциденту, відбір подій тримають постійно, а помилки пишуть з розширеним контекстом — вхідними даними та тілом відповіді.
Така комбінація дає розбір без необмеженого зростання сховища. Правила відбору подій налаштовуємо під конкретну стратегію: у журнал потрапляють угоди та відмови, а не кожен проміжний розрахунок.
Етапи впровадження: від розбору схеми до передачі регламентів
Логування угод у боті — це не виведення рядків у файл, а контур доказів: що бот отримав, як порахував, що відправив у мережу і що підтвердилося. Без нього спірну угоду не можна ні відновити, ні захистити. Робота йде етапами, і в кожного етапу є перевірний артефакт.
- Аудит бота. Розбираємо архітектуру і знаходимо точки, де народжуються події: приймання заявки, розрахунок, відправлення транзакції, підтвердження. На виході — карта потоків і перелік місць, де запис втрачається: асинхронні обробники, повтори при збоях, ручні втручання.
- Схема логування. Визначаємо склад події, ідентифікатори заявки, рахунку та транзакції, обов'язкові поля. Фіксуємо формат запису і правило, за яким подія вважається повною, а не частковою.
- Налаштування. Вбудовуємо запис у код і в середовище: буферизація, ротація, відправлення у сховище, поведінка при недоступності приймача — події дочекаються відправлення, а не зникають.
- Перевірка цілісності записів. Звіряємо журнал із фактичними балансами та історією мережі, перевіряємо безперервність послідовності й захист від підміни. Розходження розбираємо до причини, а не списуємо на збій.
- Звітність. Збираємо зрізи з тих самих записів: угоди за період, комісії, частка підтверджених операцій, інциденти. Ручна звірка в таблицях більше не потрібна.
- Регламенти експлуатації. Передаємо інструкції: як читати журнал, що робити при розходженні, як відновити сховище після збою і хто відповідає за реакцію.
Після передачі ваша команда працює з журналом самостійно; ми залишаємося на зв'язку, коли схема змінюється разом із доопрацюванням бота.
Схеми зберігання, правила відбору подій, документація
Впровадження логування — це не лише працюючий бот, а й набір артефактів, за якими ваша команда зможе розвивати й перевіряти систему без нас. Нижче — що саме передаємо в репозиторій і в базу знань при здачі.
- Схема зберігання логів — де лежать гарячі та архівні записи, за якими ключами розкладені, термін зберігання за кожним класом подій, правила ротації та стиснення.
- Правила відбору подій — які угоди, відмови та стани ордерів пишуться повністю, які зводяться в агрегати, а які йдуть лічильниками, щоб журнал не розростався.
- Словник полів і подій — опис кожного поля, типи та допустимі значення, джерело даних; за ним пишуться вибірки й будується звітність.
- Політики доступу — ролі та права на читання журналу, порядок видачі й відкликання ключів, що фіксується в аудиті звернень до самих логів.
- Вивантаження та звітність — склад зведень, періодичність формування, куди доставляються файли і як перевіряється повнота вивантаження.
- Регламент розбору розходжень — що вважається інцидентом при звірці журналу з історією угод, хто і в які строки розбирає.
- Документація щодо бота — конфігурації, точки розширення, процедури оновлення та відкату, відновлення після збою; плюс набір записаних подій для перевірки розбору після змін.
Передаємо в тому вигляді, в якому артефактами користуються: конфігурації — поряд з кодом, схеми та регламенти — в базі знань команди. За ними новий інженер піднімає стенд і повторює розбір минулих угод без звернення до нас — це і є критерій здачі.
Розбір впровадження: як усунули розходження у звітах
Замовник прийшов із ботом на трьох стратегіях: у добовому вивантаженні число угод не сходилося з випискою біржі, розходження сягало до 7% обсягу.
Причина виявилася не в стратегії — частина подій губилася між відправленням заявки та підтвердженням виконання, а частково виконані та скасовані ордери потрапляли у звіт як повністю закриті.
Звірка угод велася вручну за вивантаженням з кабінету, тому розходження знаходили через кілька днів, уже не розуміючи, на якому кроці воно виникло.
Ми перевели бота на наскрізний запис кожної події заявки.
Ключ запису — ідентифікатор заявки плюс ідентифікатор виконання: повторні підтвердження та дублі при перепідключенні відсікаються за цим ключем, а переходи станів (створена, відправлена, виконана частково, виконана, скасована) зберігаються як окремі рядки журналу на дозапис.
Журнал складається в ClickHouse, поверх нього щогодинна звірка порівнює обсяг і комісії з випискою біржі, а розходження потрапляють в окремий список із контекстом угоди — повернути можна будь-яку операцію за ключем.
Метрики до і після:
- частка угод, підтверджених звіркою: 93% → 100%;
- розходження обсягу за добу: до 7% → нуль понад округлення;
- час пошуку причини розходження: години ручного вивантаження → менше хвилини за журналом;
- коректно відображені часткові та скасовані ордери: близько 60% → 100%;
- звіт: добовий зріз сходиться з біржею без ручних правок.
Окремо закрили відкат: журнал незмінний, тому після збою запис відновлюється з останньої підтвердженої точки, а не перезбирається заново. Тепер бот звітує перед власником за тими самими цифрами, що бачить біржа, — розходження видно в момент появи, а не в кінці місяця.
Чим відрізняється логування криптобота від біржового журналу?
Біржовий журнал угод фіксує тільки те, що дійшло до майданчика: прийняті заявки, виконання, нарахування. Він не відповідає на питання, чому рішення було прийнято — розрахунок сигналу, перевірка лімітів, відхилена заявка, розрив з'єднання залишаються за кадром. Якщо помилка в логіці стратегії, журнал майданчика покаже наслідок, але не причину.
Власна історія пишеться на стороні бота і зберігає намір до відправлення заявки: вхідні дані, версію конфігурації, причину відмови, стан портфеля на момент рішення.
Завдяки цьому звірка даних стає відтворюваною: подія бота зіставляється з виконанням за ідентифікатором заявки та міткою часу в єдиній зоні.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Журнал майданчика | Потрібен лише факт виконання та рух коштів | Немає причин рішень, глибина історії задана біржею |
| Лог бота у файлах | Один процес, налагодження, короткі сесії | Втрачається при перенесенні вузла, немає єдиного пошуку |
| Власна історія в базі | Кілька стратегій, розбір інцидентів, звітність | Потрібна схема подій та обслуговування сховища |
| Журнал майданчика плюс власна історія | Звірка даних та обов'язкова звітність | Потрібна нормалізація форматів і правило розв'язання розходжень |
Тому ми ведемо обидва потоки і пов'язуємо їх регулярною звіркою. Розходження між власним логом і журналом майданчика — окремий клас інцидентів: без нього воно спливає тільки у звітності, коли відновити хід подій уже не можна.
Втрата записів, зростання обсягу та доступи: часті питання
Обсяг журналу — головний страх при вмиканні повного логування: пишемо кожну подію, кожну заявку та її виконання, тому за місяць набігає більше даних, ніж у всій іншій базі.
Вирішується це не «писати менше», а розділенням рівнів: гаряче вікно зі швидким доступом на останні тижні, далі — партиційований архів зі стисненням і своєю політикою зберігання.
Записи позначаються як незмінні, тому ні зростання обсягу, ні очищення не створюють прогалин в історії угод.
Доступ до записів будується за ролями: трейдери й підтримка бачать свої угоди, аналітик — вивантаження без чутливих полів, аудит — повний слід із відміткою, хто і коли читав.
Приватні ключі та доступи до бірж при цьому не залишають вашу інфраструктуру — ми працюємо з журналом, а не з гаманцем.
Історія вже з прогалинами — минуле можна відновити?
Ми не переписуємо минуле заднім числом: відзначаємо межі достовірних даних і позначаємо період як відновлений, щоб звітність не змішувала різне. Пропущені угоди добираємо з виписок біржі та подій мережі — наприклад, в Ethereum за журналом транзакцій сходиться більшість операцій.
Логування сповільнить бота або стане точкою відмови?
Запис іде асинхронно, в буфер, і не блокує торговий цикл: якщо журнал недоступний, угоди продовжують виконуватися, а події стають у чергу на досилання. Така схема прибирає клас відмов, коли падіння сховища зупиняло торгівлю.
Як перевірити, що записи не підмінюються?
Кожен запис пов'язується з попереднім, а добові зрізи фіксуються контрольною сумою — правку заднім числом видно відразу. Вивантаження для аудиту віддається разом із перевірними значеннями, тому звіт можна підтвердити, а не просто прийняти на слово.
Обговоримо задачу: зберемо схему запису угод під вашого бота
Точна оцінка виходить не з «плюс-мінус», а з розбору вашого сценарію: які події бот вважає угодою, де зберігається стан позиції, хто і навіщо читає звітність. Давайте обговоримо задачу на цьому рівні — після розмови у вас залишиться перелік робіт, а не загальні слова.
- Перелік подій: відкриття, часткове закриття, скасування, комісія, переказ — що саме потрапляє в журнал і з якою деталізацією.
- Джерела даних: власні логи бота, відповіді торгових майданчиків, внутрішня база — де звіряємо розходження і що вважаємо істиною.
- Схема зберігання: структура таблиць, індекси, термін зберігання, розділення свіжих та архівних записів для швидкої вибірки.
- Формат звітності: зріз за днями, інструментами та парами, вивантаження в таблицю або файл, хто і як проводить звірку.
- Поведінка при збоях: повторна доставка запису без дублів, відновлення після обриву зв'язку та перезапуску бота.
- Доступи та безпека: хто бачить журнал, які поля маскуються, де лежать ключі і як проходить їхня зміна.
- План впровадження: етапи, точки перевірки, критерії приймання та порядок розгортання без зупинки торгівлі.
За підсумками розмови зберемо технічне завдання, в якому зафіксовано склад журналу, схему зберігання та вигляд звіту. Опишіть задачу — повернемося з оцінкою робіт і планом впровадження, а також запропонуємо перший етап, що дає робочий журнал угод і першу звірку.
