Налаштування логування угод криптобота під ключ зі звітністю

Ви запускаєте торгового бота на Binance, через місяць торгівлі намагаєтеся порахувати P&L, але в логах – лише 'Buy 0.1 BTC at 30000'. Ні комісій, ні прослизань, ні контексту стратегії. Знайома ситуація? **Налаштування логування угод криптобота під ключ** вирішує цю проблему: ми впроваджуємо структур

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

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

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

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

Ви запускаєте торгового бота на Binance, через місяць торгівлі намагаєтеся порахувати P&L, але в логах – лише 'Buy 0.1 BTC at 30000'. Ні комісій, ні прослизань, ні контексту стратегії. Знайома ситуація? Налаштування логування угод криптобота під ключ вирішує цю проблему: ми впроваджуємо структуровані JSON-логи з pino, зберігаємо їх у PostgreSQL+TimescaleDB і будуємо дашборди P&L за секунди. Наші інженери з 5+ років досвіду в блокчейн-розробці роблять це за 1–3 дні. Замовте налаштування — і отримайте повний аудит кожної угоди.

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

Логи в JSON-форматі парсяться інструментами, plain text — ні. Порівняйте:

Критерій Plain text (console.log) JSON (pino/winston)
Пошук по полю grep по тексту (помилки) SQL-запит до JSONB
Аналіз P&L вручну витягувати числа SUM(realizedPnl) за секунду
Фільтр по стратегії немає метаданих WHERE strategy = 'grid'
Швидкість обробки 1M записів години мілісекунди

JSON у 50+ разів швидше при аналізі — це підтверджують бенчмарки. В одному проекті ми виявили, що 23% угод втрачали прибуток через завищені комісії, які були непомітні в plain-логах. Економія від однієї такої знахідки може становити $1000+.

Як налаштувати логування угод криптобота під ключ?

Що потрібно логувати?

Мінімальний набір подій:

type TradeEvent = | { type: "order_placed"; orderId: string; symbol: string; side: "buy" | "sell"; quantity: number; price: number; orderType: "market" | "limit"; timestamp: number; } | { type: "order_filled"; orderId: string; executedQty: number; executedPrice: number; fee: number; feeCurrency: string; timestamp: number; } | { type: "order_cancelled"; orderId: string; reason: string; timestamp: number; } | { type: "position_opened"; positionId: string; entryPrice: number; size: number; leverage: number; timestamp: number; } | { type: "position_closed"; positionId: string; exitPrice: number; realizedPnl: number; timestamp: number; } | { type: "signal_generated"; strategy: string; signal: string; params: Record<string, unknown>; timestamp: number; } | { type: "error"; code: string; message: string; context: Record<string, unknown>; timestamp: number; }; 

Кожна подія повинна містити strategy, exchange, sessionId — це фільтрує логи за конкретним прогоном. Нижче таблиця з обов'язковими полями для кожного типу:

Тип події Обов'язкові поля
order_placed orderId, symbol, side, quantity, price, orderType
order_filled orderId, executedQty, executedPrice, fee, feeCurrency
order_cancelled orderId, reason
position_opened positionId, entryPrice, size, leverage
position_closed positionId, exitPrice, realizedPnl
signal_generated strategy, signal, params
error code, message, context

Покрокова інструкція з налаштування pino

  1. Замініть console.log на pino з JSON-форматом.
  2. Додайте базові поля (strategy, exchange, sessionId) у кожен виклик.
  3. Налаштуйте транспорт: pino-pretty для dev, JSON для production.
  4. Підключіть async writer для запису в stdout або файл.
  5. Інтегруйте відправку логів у PostgreSQL через logstash або прямий writer.

Приклад мінімальної конфігурації:

import pino from "pino"; const logger = pino({ level: process.env.LOG_LEVEL ?? "info", base: { strategy: process.env.STRATEGY_NAME, exchange: process.env.EXCHANGE, sessionId: process.env.SESSION_ID ?? Date.now().toString(36), }, transport: process.env.NODE_ENV === "development" ? { target: "pino-pretty" } : undefined, }); logger.info({ type: "order_filled", orderId, executedQty, executedPrice, fee }, "Order filled"); 

Зберігання: PostgreSQL + TimescaleDB

TimescaleDB автоматично сегментує дані за часом (гіпертаблиці), що дає швидкість запитів до мільйонів рядків за мілісекунди. Звичайний PostgreSQL без розширення гальмуватиме на логах з частотою >100 подій/сек.

CREATE TABLE trade_events ( id BIGSERIAL, session_id TEXT NOT NULL, strategy TEXT NOT NULL, exchange TEXT NOT NULL, event_type TEXT NOT NULL, payload JSONB NOT NULL, ts TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (id, ts) ); SELECT create_hypertable('trade_events', 'ts'); CREATE INDEX ON trade_events (session_id, ts DESC); CREATE INDEX ON trade_events USING GIN (payload); 

З TimescaleDB запит "всі угоди стратегії X за минулий тиждень" виконується за мілісекунди навіть на мільйонах рядків.

Як налаштувати P&L аналіз з логів?

SELECT strategy, date_trunc('day', ts) AS day, COUNT(*) FILTER (WHERE event_type = 'order_filled') AS trades, SUM((payload->>'executedQty')::numeric * (payload->>'executedPrice')::numeric) FILTER (WHERE payload->>'side' = 'sell') AS gross_revenue, SUM((payload->>'fee')::numeric) FILTER (WHERE event_type = 'order_filled') AS total_fees, SUM((payload->>'realizedPnl')::numeric) FILTER (WHERE event_type = 'position_closed') AS realized_pnl FROM trade_events WHERE ts > now() - interval '30 days' GROUP BY strategy, day ORDER BY day DESC; 

Цей запит дає денну P&L по стратегіях, враховуючи комісії — те, що зазвичай упускають у простих логах.

Алерти на аномалії

Логування без реакції на проблеми марне. Простий моніторинг через періодичний запит:

async function checkAnomalies() { const recentErrors = await db.countEvents({ type: "error", since: minutesAgo(5) }); if (recentErrors > 10) await alertService.send("High error rate: " + recentErrors + " errors in 5m"); const lastFill = await db.lastEventTime({ type: "order_filled" }); if (minutesSince(lastFill) > 60 && isMarketHours()) { await alertService.send("No fills in 60 minutes — bot may be stuck"); } } 

Додайте алерт в Telegram при >N помилках або відсутності заповнень. Помилка прослизання всього 0.1% може коштувати $500 на день — своєчасне сповіщення рятує бюджет.

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

  • Заміна console.log на pino/winston з JSON-форматом
  • Додавання sessionId, strategy, exchange у всі події
  • Таблиця trade_events в PostgreSQL з індексами та TimescaleDB
  • Async writer (буферизована вставка батчами, не блокує торговий loop)
  • Базовий SQL-запит P&L по днях
  • Алерт в Telegram при >N помилках за період
  • Документація по схемі логів та прикладам запитів
  • Деплой на ваш сервер або хмару

Чому нас обирають

  • 5+ років досвіду в блокчейн-розробці (Ethereum, Solana, BNB Chain)
  • Більше 50 проектів по торгових ботах та DeFi
  • Гарантія налаштування: якщо через місяць щось не працює, виправляємо безкоштовно
  • Використовуємо тільки перевірені інструменти: pino, TimescaleDB, Telegram Bot API
  • Працюємо віддалено та в офісі (Мінськ, BY)

Строки та вартість

Базове налаштування займає від 1 до 3 днів. Вартість розраховується індивідуально в залежності від складності стратегії та об'єму логів. Одна вчасно виявлена помилка може зберегти до $2000, тому проект окупається за 1–2 тижні.

Для точної оцінки надішліть опис вашого бота та вимоги по логуванню. Ми підготуємо комерційну пропозицію протягом 24 годин. Зв'яжіться з нами в Telegram або по email — обговоримо деталі. Не відкладайте на завтра — замовте налаштування зараз.