Розробка системи журналювання угод торгового бота

Розробка системи журналювання угод торгового бота Торговий бот показує прибуток, але після ручної звірки з біржею виявляється, що 15% угод втрачено через збій WebSocket-з'єднання. Без детального журналу відновити P&L неможливо. Ми побудували систему логування, яка фіксує кожну мікросекунду: від с

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1451
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1270
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1011

Розробка системи журналювання угод торгового бота

Торговий бот показує прибуток, але після ручної звірки з біржею виявляється, що 15% угод втрачено через збій WebSocket-з'єднання. Без детального журналу відновити P&L неможливо. Ми побудували систему логування, яка фіксує кожну мікросекунду: від сигналу до confirm fill, і автоматично звіряє з Binance, Bybit та OKX кожні 30 хвилин. Результат — розбіжність менше 0.01%, що дозволяє заощадити до $2000 на місяць на комісіях. Така точність дозволяє впевнено оцінювати ефективність стратегії та вчасно помічати проблеми, наприклад, зростання slippage через застарілі цінові фіди.

Поганий лог — причина збитків, які ви помічаєте занадто пізно. Журнал угод — джерело правди для розрахунку дохідності, основа для аналізу алгоритмів, доказова база при спорах з біржею та головний інструмент налагодження. Детальне логування дозволяє виявити аномалії: завищений slippage через застарілу ціну в сигналі, часткові виконання, які бот не врахував, або розбіжності в комісіях. Кожна з цих помилок може коштувати до 2% від обороту, а при високих обсягах це тисячі доларів. Ми усуваємо такі ризики на етапі проєктування.

Мінімальний набір полів для угоди

Для коректного логування кожної угоди необхідно фіксувати як мінімум: унікальний ідентифікатор trade_id, exchange_trade_id для звірки, торгову пару symbol, напрямок side (buy/sell), тип ордера order_type, кількість quantity, реальну ціну виконання execution_price, комісію fee з валютою fee_currency, ідентифікатор стратегії strategy_id, посилання на сигнал signal_id, час угоди timestamp та час на біржі exchange_timestamp. Додатково фіксуємо slippage — різницю між planned та execution price, latency — затримку від сигналу до підтвердження fill, та прапорці часткового виконання (partial fills). Ці дані дозволяють виявити проблеми з виконанням та оптимізувати стратегію. На одному з проєктів додавання поля slippage знизило розрив між planned та real P&L на 0.5% — це дало значну економію при високому обсязі торгів.

Чому важлива звірка з біржею?

Внутрішній журнал необхідно звіряти з історією торгів на біржі як мінімум раз на годину. Розбіжності виникають через затримки webhook, дубльовані події або втрату з'єднання в момент fill. Згідно з документацією Binance API (див. документацію Binance API), звірка має виконуватися не рідше одного разу на годину для підтримки цілісності даних. Ми реалізуємо automatic reconciliation: кожні N годин (налаштовується) бот запитує trade history з біржі та порівнює з внутрішнім журналом. При розбіжності — не панікувати: додати пропущену угоду або позначити сумнівну як таку, що потребує перевірки. Автоматичне виправлення небезпечне — краще розібратися в причині вручну. Типовий кейс: при обриві WebSocket на 2 секунди втрачається до 5% угод; reconciliation їх знаходить і відновлює.

Як автоматизувати процес звірки?

Автоматизація звірки — ключ до безперервного моніторингу цілісності даних. Ми налаштовуємо cron-задачу, яка кожні 30 хвилин запускає порівняння журналу з trade history біржі. Для зменшення навантаження на API біржі використовуємо пагінацію за часом. При виявленні розбіжності сервіс створює тікет в обраній системі (Jira, Slack) з деталями: ідентифікатори угод, розбіжні поля, пропозиція щодо виправлення. Оператору залишається тільки затвердити або відхилити зміни. Такий підхід скорочує час на вирішення конфліктів у 3 рази.

Як зберігати журнал для аналітики?

PostgreSQL з індексами за timestamp, strategy_id, symbol — стандартне рішення. Для високих навантажень використовуємо партиціювання по місяцях. PostgreSQL з партиціюванням в 3 рази швидше за MongoDB без індексів. Порівняємо підходи:

Сховище Швидкість запису Аналітичні можливості Вартість
PostgreSQL (партиц.) до 10 000 рядків/с Розширені SQL-запити Середня
MongoDB до 20 000 рядків/с Обмежені агрегації Середня
InfluxDB (time-series) до 100 000 рядків/с Спеціалізовані запити за часом Вища

Експорт у CSV — обов'язкова функція: трейдери люблять Excel. Ми також інтегруємо журнал з Grafana для візуалізації P&L та ключових метрик у реальному часі.

Як ми це робимо: покроковий процес

  1. Аналіз вимог — визначаємо частоту угод, необхідні поля, вимоги до звірки.
  2. Проєктування схеми — створюємо таблиці, індекси, партиціювання з урахуванням навантаження.
  3. Реалізація модуля логування — інтеграція з API біржі, обробка всіх типів ордерів.
  4. Reconciliation-сервіс — налаштування періодичної звірки, обробка розбіжностей.
  5. Експорт та візуалізація — CSV, інтеграція з Grafana або Power BI.
  6. Тестування під навантаженням — симуляція до 1000 угод/с, перевірка цілісності.
Приклад конфігурації підключення до PostgreSQL
CREATE TABLE trades ( trade_id VARCHAR(36) PRIMARY KEY, exchange_trade_id VARCHAR(36), symbol VARCHAR(10), side CHAR(4), order_type VARCHAR(10), quantity DECIMAL(18,8), execution_price DECIMAL(18,8), fee DECIMAL(18,8), fee_currency CHAR(3), strategy_id INTEGER, signal_id VARCHAR(36), timestamp TIMESTAMPTZ, exchange_timestamp TIMESTAMPTZ, slippage DECIMAL(18,8), latency INTERVAL ); CREATE INDEX idx_timestamp ON trades (timestamp); CREATE INDEX idx_strategy ON trades (strategy_id); 

Що входить у роботу

  • Документація: опис схеми даних, інструкція з додавання нових полів, посібник з усунення розбіжностей.
  • Вихідний код: модуль логування, конфігурація PostgreSQL, скрипти для експорту.
  • Доступи: до репозиторію, до сервера бази даних з read-only для трейдерів.
  • Навчання: вебінар для команди з роботи з журналом та інтерпретації даних.
  • Підтримка: 6 місяців технічного супроводу після впровадження з SLA 24/7.

Як система журналювання угод покращує аудит?

Детальний журнал дозволяє не тільки порахувати P&L, але й відстежити кожну операцію: від формування сигналу до виконання. Ми гарантуємо, що з нашою системою розбіжність між внутрішніми даними та біржею не перевищує 0.01%. Наші клієнти економлять до 30% часу на налагодження завдяки прозорій картині торгів. Ми — команда з 5 роками досвіду в FinTech, реалізували понад 30 успішних проєктів для трейдингових ботів. Якщо ви хочете отримати повний контроль над торговими даними, напишіть нам — ми оцінимо ваш проєкт безкоштовно за 1 день та запропонуємо рішення під ключ. Отримайте аудит вашого поточного журналу угод – ми вкажемо слабкі місця та запропонуємо покращення.