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

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

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

Плохой лог — причина убытков, которые вы замечаете слишком поздно. Журнал сделок — источник правды для расчёта доходности, основа для анализа алгоритмов, доказательная база при спорах с биржей и главный инструмент отладки. Детальное логирование позволяет выявить аномалии: завышенный slippage из-за устаревшей цены в сигнале, частичные исполнения, которые бот не учёл, или расхождения в комиссиях. Каждая из этих ошибок может стоить до 2% от оборота, а при высоких объёмах это тысячи долларов. Мы устраняем такие риски на этапе проектирования.

Минимальный набор полей для сделки

Ниже приведён минимальный набор полей для каждой сделки. Каждое поле критично для последующего аудита.

Дополнительно фиксируем slippage — разницу между planned и execution price, latency — задержку от сигнала до подтверждения fill, и флаги частичного исполнения (partial fills). Эти данные позволяют выявить проблемы с исполнением и оптимизировать стратегию. На одном из проектов добавление поля slippage снизило разрыв между planned и real P&L на 0.5% — это дало значительную экономию при высоком объёме торгов.

Почему важна сверка с биржей?

Внутренний журнал необходимо сверять с историей торгов на бирже как минимум раз в час. Расхождения возникают из-за задержек webhook, дублированных событий или потери соединения в момент fill. Согласно документации 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 без индексов. Экспорт в CSV — обязательная функция: трейдеры любят Excel. Мы также интегрируем журнал с Grafana для визуализации P&L и ключевых метрик в реальном времени.

Как мы это делаем: пошаговый процесс

1. Анализ требований — определяем частоту сделок, необходимые поля, требования к сверке.
2. Проектирование схемы — создаём таблицы, индексы, партиционирование с учётом нагрузки.
3. Реализация модуля логирования — интеграция с API биржи, обработка всех типов ордеров.
4. Reconciliation-сервис — настройка периодической сверки, обработка расхождений.
5. Экспорт и визуализация — CSV, интеграция с Grafana или Power BI.
6. Тестирование под нагрузкой — симуляция до 1000 сделок/с, проверка целостности.

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 для трейдеров.
• Обучение: вебинар для команды по работе с журналом и интерпретации данных.
• Поддержка: несколько месяцев сопровождения после внедрения.

Как система журналирования сделок улучшает аудит?

Детальный журнал позволяет не только посчитать P&L, но и отследить каждую операцию: от формирования сигнала до исполнения. Мы гарантируем, что с нашей системой расхождение между внутренними данными и биржей не превышает 0.01%. Наши клиенты экономят до 30% времени на отладку благодаря прозрачной картине торгов. Если вы хотите получить полный контроль над торговыми данными, свяжитесь с нами для консультации — мы подготовим описание проекта под вашу стратегию. Получите аудит вашего текущего журнала сделок – мы укажем слабые места и предложим улучшения.