Настройка логирования сделок криптобота под ключ с отчетностью

Почему логирование криптобота рассыпается на первом же сбое

Бот отправляет заявку, биржа не отвечает дольше заданного интервала, позиция остаётся открытой — а в журнале одна строка про ошибку соединения. Дальше начинается реконструкция по косвенным признакам: сверка балансов, выгрузки из личного кабинета, сопоставление времени событий. На такую диагностику сбоя уходят часы, и она всё равно не отвечает на главный вопрос — была сделка или только попытка.

Причина в том, что события пишутся не сквозным потоком, а по частям: сигнал стратегии — в одном месте, ответ исполнения — во втором, состояние позиции — в третьем. Когда один из участников падает, соседние записи теряют связь, и потеря сделок перестаёт быть проверяемым фактом. Логирование криптобота в таком виде фиксирует факт падения, но не цепочку решений, которая к нему привела, поэтому каждый сбой торгового бота приходится объяснять заново.

Отдельное узкое место отчётности — формат записи. Свободный текст удобен человеку, но не поддаётся группировке: нельзя посчитать долю отклонённых заявок, время от сигнала до подтверждения, частоту повторов по одному инструменту. Пока эти величины не выводятся из журнала, спор о том, виноват рынок или логика бота, остаётся спором о вкусах.

Доверие к стратегии держится на воспроизводимости: по журналу сделка должна собираться от сигнала до закрытия позиции — с идентификатором заявки, меткой времени и версией конфигурации. Ниже разбираем, как это закрывается.

Что меняется после внедрения: разбор сбоя и полнота истории

До настройки журналирования сбой в боте выглядел так: ордер ушёл на биржу, ответ не разобрался, позиция осталась открытой, а в логах — одна строка без идентификатора. Разбор такого случая занимал часы: приходилось сверять выгрузки с биржи, баланс кошелька и переписку в мессенджере, чтобы восстановить порядок событий.

Мы переводим журналирование на событийную модель. Каждое действие — расчёт сигнала, выставление ордера, подтверждение, частичное исполнение, отмена, пересчёт позиции — пишется отдельной записью со сквозным идентификатором корреляции, меткой времени и снимком входных параметров. Записи попадают в неизменяемый журнал, поверх которого строится отчётность по сделкам.

Полнота истории сделок перестаёт зависеть от того, успел ли бот дописать файл до перезапуска: запись подтверждается до перехода к следующему шагу, поэтому пропусков в истории не остаётся. Время разбора инцидента падает с часов до минут — по идентификатору поднимается вся цепочка от сигнала до исполнения, включая ответы биржи и превышения времени ожидания.

Воспроизводимость состояния даёт проигрывание журнала в тестовом контуре: поведение бота на исторических данных повторяется шаг в шаг. Это убирает целый класс отказов — потерю состояния после рестарта, дубли ордеров и «зависшие» позиции, которые раньше находили только по расхождению баланса, — и напрямую повышает устойчивость бота. Панель мониторинга в Grafana показывает расхождения в реальном времени, а не постфактум.

Режимы записи: полный поток, выборка событий, только ошибки

Режим записи определяет, что вообще удастся восстановить при разборе инцидента. Полный поток сохраняет каждое событие — заявки, ответы биржи, изменения баланса и состояния, поэтому объём хранилища растёт линейно с активностью бота. Запись только ошибок даёт минимальный след: исключение видно, а цепочка решений, которая к нему привела, — уже нет.

На практике режимы не выбирают по одному: полный поток включают на коротком окне вокруг релиза или инцидента, отбор событий держат постоянно, а ошибки пишут с расширенным контекстом — входными данными и телом ответа. Такая комбинация даёт разбор без неограниченного роста хранилища. Правила отбора событий настраиваем под конкретную стратегию: в журнал попадают сделки и отказы, а не каждый промежуточный расчёт.

Этапы внедрения: от разбора схемы до передачи регламентов

Логирование сделок в боте — это не вывод строк в файл, а контур доказательств: что бот получил, как посчитал, что отправил в сеть и что подтвердилось. Без него спорную сделку нельзя ни восстановить, ни защитить. Работа идёт этапами, и у каждого этапа есть проверяемый артефакт.

1. Аудит бота. Разбираем архитектуру и находим точки, где рождаются события: приём заявки, расчёт, отправка транзакции, подтверждение. На выходе — карта потоков и перечень мест, где запись теряется: асинхронные обработчики, повторы при сбоях, ручные вмешательства.
2. Схема логирования. Определяем состав события, идентификаторы заявки, счёта и транзакции, обязательные поля. Фиксируем формат записи и правило, по которому событие считается полным, а не частичным.
3. Настройка. Встраиваем запись в код и в окружение: буферизация, ротация, отправка в хранилище, поведение при недоступности приёмника — события дожидаются отправки, а не пропадают.
4. Проверка целостности записей. Сверяем журнал с фактическими балансами и историей сети, проверяем непрерывность последовательности и защиту от подмены. Расхождения разбираем до причины, а не списываем на сбой.
5. Отчётность. Собираем срезы из тех же записей: сделки за период, комиссии, доля подтверждённых операций, инциденты. Ручная сверка в таблицах больше не нужна.
6. Регламенты эксплуатации. Передаём инструкции: как читать журнал, что делать при расхождении, как восстановить хранилище после сбоя и кто отвечает за реакцию.

После передачи ваша команда работает с журналом самостоятельно; мы остаёмся на связи, когда схема меняется вместе с доработкой бота.

Схемы хранения, правила отбора событий, документация

Внедрение логирования — это не только работающий бот, но и набор артефактов, по которым ваша команда сможет развивать и проверять систему без нас. Ниже — что именно передаём в репозиторий и в базу знаний при сдаче.

• Схема хранения логов — где лежат горячие и архивные записи, по каким ключам разложены, срок хранения по каждому классу событий, правила ротации и сжатия.
• Правила отбора событий — какие сделки, отказы и состояния ордеров пишутся целиком, какие сводятся в агрегаты, а какие идут счётчиками, чтобы журнал не разрастался.
• Словарь полей и событий — описание каждого поля, типы и допустимые значения, источник данных; по нему пишутся выборки и строится отчётность.
• Политики доступа — роли и права на чтение журнала, порядок выдачи и отзыва ключей, что фиксируется в аудите обращений к самим логам.
• Выгрузки и отчётность — состав сводок, периодичность формирования, куда доставляются файлы и как проверяется полнота выгрузки.
• Регламент разбора расхождений — что считается инцидентом при сверке журнала с историей сделок, кто и в какие сроки разбирает.
• Документация по боту — конфигурации, точки расширения, процедуры обновления и отката, восстановление после сбоя; плюс набор записанных событий для проверки разбора после изменений.

Передаём в том виде, в котором артефактами пользуются: конфигурации — рядом с кодом, схемы и регламенты — в базе знаний команды. По ним новый инженер поднимает стенд и повторяет разбор прошлых сделок без обращения к нам — это и есть критерий сдачи.

Разбор внедрения: как устранили расхождения в отчётах

Заказчик пришёл с ботом на трёх стратегиях: в суточной выгрузке число сделок не сходилось с выпиской биржи, расхождение доходило до 7% объёма. Причина оказалась не в стратегии — часть событий терялась между отправкой заявки и подтверждением исполнения, а частично исполненные и отменённые ордера попадали в отчёт как закрытые полностью. Сверка сделок велась вручную по выгрузке из кабинета, поэтому расхождение находили через несколько дней, уже не понимая, на каком шаге оно возникло.

Мы перевели бота на сквозную запись каждого события заявки. Ключ записи — идентификатор заявки плюс идентификатор исполнения: повторные подтверждения и дубли при переподключении отсекаются по этому ключу, а переходы состояний (создана, отправлена, исполнена частично, исполнена, отменена) сохраняются как отдельные строки журнала на дозапись. Журнал складывается в ClickHouse, поверх него ежечасная сверка сверяет объём и комиссии с выпиской биржи, а расхождения попадают в отдельный список с контекстом сделки — вернуть можно любую операцию по ключу.

Метрики до и после:

• доля сделок, подтверждённых сверкой: 93% → 100%;
• расхождение объёма за сутки: до 7% → ноль сверх округления;
• время поиска причины расхождения: часы ручной выгрузки → меньше минуты по журналу;
• корректно отражённые частичные и отменённые ордера: около 60% → 100%;
• отчёт: суточный срез сходится с биржей без ручных правок.

Отдельно закрыли откат: журнал неизменяем, поэтому после сбоя запись восстанавливается из последней подтверждённой точки, а не пересобирается заново. Теперь бот отчитывается перед владельцем по тем же цифрам, что видит биржа, — расхождение видно в момент появления, а не в конце месяца.

Чем отличается логирование криптобота от биржевого журнала?

Биржевой журнал сделок фиксирует только то, что дошло до площадки: принятые заявки, исполнения, начисления. Он не отвечает на вопрос, почему решение было принято — расчет сигнала, проверка лимитов, отклоненная заявка, разрыв соединения остаются за кадром. Если ошибка в логике стратегии, журнал площадки покажет следствие, но не причину.

Собственная история пишется на стороне бота и сохраняет намерение до отправки заявки: входные данные, версию конфигурации, причину отказа, состояние портфеля на момент решения. За счет этого сверка данных становится воспроизводимой: событие бота сопоставляется с исполнением по идентификатору заявки и метке времени в единой зоне.

Поэтому мы ведем оба потока и связываем их регулярной сверкой. Расхождение между собственным логом и журналом площадки — отдельный класс инцидентов: без него оно всплывает только в отчетности, когда восстановить ход событий уже нельзя.

Потеря записей, рост объёма и доступы: частые вопросы

Объём журнала — главная страшилка при включении полного логирования: пишем каждое событие, каждую заявку и её исполнение, поэтому за месяц набегает больше данных, чем во всей остальной базе. Решается это не «писать поменьше», а разделением уровней: горячее окно с быстрым доступом на последние недели, дальше — партиционированный архив со сжатием и своей политикой хранения. Записи помечаются как неизменяемые, поэтому ни рост объёма, ни очистка не создают пробелов в истории сделок.

Доступ к записям строится по ролям: трейдеры и поддержка видят свои сделки, аналитик — выгрузку без чувствительных полей, аудит — полный след с отметкой, кто и когда читал. Приватные ключи и доступы к биржам при этом не покидают вашу инфраструктуру — мы работаем с журналом, а не с кошельком.

Логирование замедлит бота или станет точкой отказа?

Запись идёт асинхронно, в буфер, и не блокирует торговый цикл: если журнал недоступен, сделки продолжают исполняться, а события встают в очередь на досылку. Такая схема убирает класс отказов, когда падение хранилища останавливало торговлю.

Как проверить, что записи не подменяются?

Каждая запись связывается с предыдущей, а суточные срезы фиксируются контрольной суммой — правку задним числом видно сразу. Выгрузка для аудита отдаётся вместе с проверочными значениями, поэтому отчёт можно подтвердить, а не просто принять на слово.

Обсудим задачу: соберём схему записи сделок под вашего бота

Точная оценка получается не из «плюс-минус», а из разбора вашего сценария: какие события бот считает сделкой, где хранится состояние позиции, кто и зачем читает отчётность. Давайте обсудим задачу на этом уровне — после разговора у вас останется перечень работ, а не общие слова.

• Перечень событий: открытие, частичное закрытие, отмена, комиссия, перевод — что именно попадает в журнал и с какой детализацией.
• Источники данных: собственные логи бота, ответы торговых площадок, внутренняя база — где сверяем расхождения и что считаем истиной.
• Схема хранения: структура таблиц, индексы, срок хранения, разделение свежих и архивных записей для быстрой выборки.
• Формат отчётности: срез по дням, инструментам и парам, выгрузка в таблицу или файл, кто и как проводит сверку.
• Поведение при сбоях: повторная доставка записи без дублей, восстановление после обрыва связи и перезапуска бота.
• Доступы и безопасность: кто видит журнал, какие поля маскируются, где лежат ключи и как проходит их смена.
• План внедрения: этапы, точки проверки, критерии приёмки и порядок выката без остановки торговли.

По итогам разговора соберём техническое задание, в котором зафиксированы состав журнала, схема хранения и вид отчёта. Опишите задачу — вернёмся с оценкой работ и планом внедрения, а также предложим первый этап, дающий рабочий журнал сделок и первую сверку.