Bot CEX DEX 開発ログ

🛠️開発記録#281(2025/8/13)本日の作業ログ

MMbot現状サマリー

✅ 達成できたこと（技術）

  • /metrics 空問題を完全解消：Exporterが単一REGISTRYを確実に配信、registry_build_info と monitor_boot_info の reg_id一致を確認。既定Collector（process_, python_gc_）も露出。
  • ライフサイクル硬化：メイン非デーモン化、アップタイム/livenessメトリクス（monitor_alive_ticks_total）で生存可視化。
  • 制御サーバー整備：/emit 実装＆CONTROL_TOKEN対応。
  • Prometheus/Grafana配線の土台：録画ルールファイルあり、ダッシュボード/アラートのクエリ雛形も準備済み。
  • レジストリ・ハブ：重複防止・スレッドセーフ・Info対応・自己診断メトリクスを実装。

⛳ 収益化に直結する技術課題（未完）

  • レイテンシ計測の本線：mm_lat_total_agg_seconds_(bucket|count|sum) が 常時出る状態の最終確認が未完（/emit→observe→Prometheus→録画ルールまでのE2E）。
  • p99/health の自動更新：ember_* メトリクスが 確実に増える状態の常時監視が未完（起動・例外時の診断含む）。
  • アラートの実データ検証：低QPS時のノイズ抑制（for条件、silence運用）の微調整が未検証。
  • 本番運用の運用設計：エラーバジェット・当番/オンコール手順、ログ/トレースの保存期間とコスト。

収益化ロードマップ（個人運用版）

1) 収益化に向けた実務タスク（個人のPnL直結）

  • 戦略と市場の確定：対象銘柄・時間帯・板厚・手数料/リベート・約定特性（ヒット/リフト vs パッシブ）を一枚に整理。
  • 運用フローを固定：
    Backtest → Paper(24–48h) → 少額Live(1×) → 段階引き上げ(2×, 5×, 10×)。各段階の昇格/降格条件を数値で明文化。
  • リスク・キルスイッチ：
    ・日次DD閾値 / 単筆最大損 / 在庫上限 / 変動率スロットル
    ・p99遅延 > 閾値 or エラー連発で新規発注停止（/metrics連動）
  • オブザーバビリティを収益に直結：
    ・遅延：job:mm_total_p99_ms:5m / mm_lat_*
    ・健全性：ember_health / monitor_alive_ticks_total
    ・約定KPI：fill率、reject率、cancel-to-trade、スリッページ（自前集計でもOK）
  • 資金配分ルール：日次リスク限度、段階的ベットサイズ、週次で上限見直し。
  • 法務/運用最低限：取引所規約・API鍵管理・ログ保存方針・税務記録。

2) 収益化ラインの構築（今週やること）

  • Paper 24–48h：本番と同じ配信/板で発注だけドライラン。
    監視：job:mm_total_p99_ms:5m が安定<250ms、ember_health==1 を維持。
  • 少額Live投入（証拠金/現物どちらでも可）：最小数量で1日運転。
    キルスイッチ：
    • p99 > 250ms 2分以上 OR reject率>3% OR 日次DD>1R → 新規停止
  • ログ→集計：トレードCSV（約定/取消/手数料）を日次集計、期待値と手数料後のネットを確認。
  • 段階引き上げ：2×→5×→10×（各段階で3日連続で目標クリアしたら昇格）。
  • ダッシュボード：p99 / fill / reject / PnL を1画面で常時監視（既存Prom＋GrafanaにP/L系を追加パネル）。

3) 初月の“稼ぐための最小KPI”

  • PnL系
    • 月次ネットPnL > 0（手数料・スリッページ込み）
    • 日次期待値（per trade）> 0 を5営業日連続
    • 最大ドローダウン < 5–10%
  • リスク/約定
    • fill率 > 35–50%（戦略に応じて）
    • reject率 < 2–3%、cancel-to-trade 比 上限設定
  • レイテンシ/可用性
    • job:mm_total_p99_ms:5m < 250ms（連続2分超でキル）
    • 稼働率 ≥ 99.0%、monitor_alive_ticks_total が途切れないこと

4) 次の具体アクション（チェックリスト）

  1. /emit→mm_lat_* がcount/sum増加を再確認
  2. ember_* が定期tickし ember_health==1 を維持
  3. Paper運転を48h、閾値違反で自動停止動作を確認
  4. Live最小サイズで1日、PnLと手数料後のネットを検証
  5. ダッシュボードにPnL/約定KPIパネルを追加
  6. 昇格/降格・日次DD・週次上限のルールをYAML化（リポジトリに格納）

オンチェーン清算スナイプ開発ログ

いま達成できていること

  • 観測基盤の再構築
    単一レジストリ＋メトリクス鯖（:8013）、心拍・起動・合議・チャネル流量などの計測を統一。
  • イベント整流／シリーズ化
    event_kind 正規化、series_id 付与、シリーズ集約の基本線が稼働。
  • 2-of-4 合議スコアリング
    trade_cluster / bbo_crash / l2_thin / oi_z / mark_jump を統合。セルフテストで 合議成立確認（PASS）。
  • カナリア運用の土台
    .env-canary に暫定ワイド設定（JOIN/CLOSE/TTL/α）、執行の安全弁（notional cap など）を環境変数化。
  • セルフテスト＆オフライン検証
    metrics スモーク、合議自己診断、NDJSON リプレイ、メトリクスダンプを揃え、ターミナル無しでも検証可能。

まだの課題（“稼ぐ”までのギャップ）

  • 実運用での一貫動作の確認不足
    実チャネル → ハンドラ → シリーズ合流 → 合議 → 執行 のライブ観測（連続運転）データが未蓄積。
  • PnL台帳／実約定の最小線
    fills/fees の永続化・日次PnL・連続損失ガード（MAX_CONSEC_LOSS）など、お金の記録が未完成。
  • パラメータ最適化は暫定
    JOIN/CLOSE/TTL/α は“合議優先ワイド”。レイテンシ×ヒット率の現場最適が未実施。
  • アラートとSLO
    staleness・timeout・合議レイテンシ・影約定成功率などのSLO/Alertが未整備。

直近やるべきこと（順番＝収益最短）

  1. JOIN/CLOSE の最適化（オフライン一発）
    scripts/analyze_consensus_from_file.py でスイープ → keep≥90% & p95最小を採用。
    → .env-canary 反映（EXEC_TTL_MS = p95+30ms / EXEC_ALPHA = 0.20で過追随抑制）。
  2. ランタイムで“合議レイテンシ”を可視化
    consensus_latency_ms を導入（p50/p95を常時計測）。
    Go条件：p95 ≤ 350ms、keep≥90% を維持。
  3. PnL台帳（最小）＋影約定の記録
    PnLLedger を入れて、shadow の fills/fees を必ず保存。
    昇格条件：影の“想定EV/トレード > 手数料＋追随損”が連続N日プラス。
  4. 超低ノッチ Canary（実約定ON）
    EXEC_MODE=canary、EXEC_NOTIONAL_CAP_USD=50、DAILY_LOSS_LIMIT_USD と MAX_CONSEC_LOSS を設定。
    監視：shadow_exec_result_total / pnl_realized_usd_total / consensus_latency_ms。
  5. 小さなグリッドで TTL/α を微調整
    成功率と過追随率を見ながら TTL（±30〜50ms）、α（0.15–0.25）を調整。
    維持するKPI：
    • シャドー実行→本番実行の fill 成功率の低下 ≤ 10%
    • 実運用の1トレードあたりEVが手数料差引後プラス

“稼げる”の判断基準（Go/No-Go）

  • 技術SLO：
    合議keep≥90% / consensus_latency_ms p95 ≤ 350ms / stalenessブロック発火率低いこと
  • 執行KPI：
    実 fill 成功率 ≥ 影の90% / リジェクト率＆タイムアウト率の低さ
  • 収益KPI：
    手数料込みの日次PnL > 0 を 5 営業日連続、かつ最大ドローダウンが許容範囲内

一言まとめ

  • 作るべき“もの”は揃った（観測・検知・合議・テスト）。
  • “稼ぐ”には 合議の遅延最適化 → PnL台帳 → 影→実の安全昇格 をテンポよく回すだけ。
  • まずは JOIN/CLOSE の最適化→.env反映→PnL台帳→超低ノッチCanary の順で行う。

CEX/DEX arb bot開発ログ

達成できたこと（基盤はOK）

  • 安定スキャナ稼働：RPS=8 / HEDGE_DELAY_MS=80ms で連続運転、直近エラー率 ≈ 0.10% 前後（SLO=0.2%以下を満たす設定を確立）
  • 監視系：Prometheus shim(:9106) で arbbot_p99_ms / arbbot_error_rate / arbbot_degraded を配信。ログは /tmp/burnin_current.log に集約。
  • シグナル検出：ネットエッジ（手数料＋想定スリップ控除後）で 閾値≥40bps を通知するウォッチャーを整備（mac通知対応）。
  • 運用ツール：手動トレード 記録CSV と 集計 スクリプトを用意（勝率・PnL・手数料/スリップ統計）。

いまの課題（稼ぐ前に詰める）

  • p99=0.0ms 表示の妥当性：集計ロジックかサンプル母集団の問題の可能性（0msは実測としては不自然）。
  • RPS=10 は未合格：高負荷時にエラー率上昇（429/ReadTimeout）。RPS=8〜9が実用レンジ。
  • 公式メトリクス(:9001)未復旧：shim(:9106)で代替中。将来の計測一元化が未完。
  • “論理エラー率”が未計測：ヘッジの両レッグとも失敗した割合（=実害）が見えていない。
  • 実トレード未実施：手数料ティアと実スリップの実測がないと、ネットエッジ閾値の最適化ができない。

次にやるべきこと（“最初の1ドル”へ直結）

  1. 10本の小額（$10）手動約定を実施
    • 対象：SOL/USDC（DEX: Jupiter / CEX 片側）
    • 記録：CSVに fill価格・手数料・実スリップ・約定時間 を必ず残す
    • 成功基準：勝率>60%、平均ネットエッジ>40bps、1件あたり正のPnL を確認
  2. ネットエッジの現実合わせ（閾値/控除値の再キャリブレーション）
    • 初期値：手数料 30bps、想定スリップ 20bps（保守）
    • 実測後に slip と fees を実値に更新 → ウォッチャーの threshold-net-bps を再調整
  3. 計測の是正（最優先）
    • p99集計：0msサンプルやキャッシュ命中は除外し、ネット到達のみで p50/p95/p99 を出す
    • 論理エラー率：minute行に logical_err_rate（両レッグ失敗/論理要求）を追加してSLOの指標を現実化
  4. 運用ノブの明確化
    • ダウンシフト：RPS=8 / HEDGE=80ms / BURST=16（SLO超過時に即切替）
    • ステップアップ：安定が続けば RPS=9 / HEDGE=60–70ms を試す（RPS=10は後回し）
  5. メトリクスの一元化（余力で）
    • :9001 復旧 or shimを本運用に格上げ（ダッシュボード/アラートのルール化）

直近のゴール（実践タスク）

  • ネットエッジ≥40bps が出たら $10 で10件 実約定 → CSVへ即記録
  • trade_summary.py で 勝率 / 平均PnL / fees & slip 統計 を確認
  • 実測に基づきウォッチャーの fees/slip/threshold を更新
  • minuteサマリに logical_err_rate を追加（計測の正確化）

これで「スキャンが安定して動く状態」から「実トレードで稼ぐ状態」へ移行できる。まず10本の実測で“数字”を固め、そこから自動化とサイズ拡大へ進む。

ショート系 botスナップショット（いま）

  • 信頼性基盤：メトリクス常駐・診断・サーキット・キルスイッチ・トレースID ✅
  • 運用ガード：Canary（比率/上限/ゲート/スモーク/Preflight）✅
  • 可観測性：Prometheus録画/アラート定義・Makeタスク・Runbook同梱 ✅
  • パフォーマンス基盤：p99最適化の実装（P1〜P7）✅
  • E2E：トレースID貫通、ポートフォリオ・メトリクス露出 ✅

達成できたこと（Done）

  • “空っぽ /metrics”の恒久対策：metrics-serve 常駐、metrics-diag でREGISTRY/HTTP整合性確認。multiprocess対応（reader/writerの集約）実装済み。
  • エラー耐性：エラー分類＋カテゴリ別サーキット、CLI error-sim で検証。
  • トレース：contextvarsで 同一trace_id貫通（CLI→エンジン→ラッパ→ログ）。
  • Canary運用：設定/Preflight/Smoke/Statusコマンド、サンプリング（固定5%→上書き可）、安全柵（max notional / kill-switch / circuit / symbol制限）。
  • Prometheus：recording/alert rules 追加、prometheus-check/prometheus-reload 用意、Runbook記載。
  • ポートフォリオ：--with-portfolio で equity/position を /metrics 露出。
  • 性能計測の土台：req→ack / cancel ヒストグラム、レイテンシ分解メトリクス、HTTPセッション再利用・uvloop等のP1〜P7実装。

主要な課題（Open）

  1. ヒストグラムが出ないケースがある
    • 原因パターン：
      • PROMETHEUS_MULTIPROC_DIR が reader と writer で不一致
      • モック経路が ReqAckTimer/CancelTimer を通らないコードパス
    • 対応：SOPで 共通DIR固定＋ラッパで 必ず計測 に一本化（パッチ適用済みか要確認）。
  2. アラートの“実弾”発火確認が未完全
    • Prometheus側UI/AlertsでFiring確認のドリルを一度完了させる必要あり。
  3. 実弾テスト（Testnet）接続前
    • Bybit等のAPIキー・精度/ロット/ティック確認、最小サイズ・手数料・滑りの反映。
  4. 収益モニタリングの線表が未整備
    • PnL/勝率/ドローダウン/手数料/稼働資本効率などのダッシュボード整備が必要。

直近でやるべきこと（Next）

A. p99計測の確実化（最優先）

  • metrics-serve（reader）と engine-dryrun（writer）両方で PROMETHEUS_MULTIPROC_DIR=/tmp/bsb_mp を固定。
  • engine-dryrun --bypass-canary を 30回回し、short_req_ack_ms_* / short_cancel_ms_* の _bucket/_sum/_count 出力を確認。
  • 期待SLO：req→ack p99 < 250ms、cancel p99 < 300ms（recording ruleで確認）。

B. アラート・ドリル（優先度高）

  • error-sim --category network --fatal 3 で short_circuit_state{category="network"}==2 を作り、Prometheusで Firing を確認→Runbookの手順通りに 解消 まで。

C. Testnet Canary（今週）

  • APIキー設定、preflight 合格（TRADE_ENABLED=true / DRY_RUN=false / EXCHANGE_MODE=testnet）。
  • canary-smoke --symbol BTCUSDT（最小ノッチ・即キャンセル）で req→ack/cancel p99 と リジェクト率 を収集。
  • Canary比率は最初 1–2%、max_notional を極小に。

D. 収益化に直結する可観測性（今週）

  • 収益系メトリクス追加：pnl_usdt_total, fees_usdt_total, win_rate, max_drawdown, exposure_usdt。
  • ダッシュボード：SLO（p99系）、健全性（エラー率/サーキット時間）、収益（PnL/手数料/滑り）。

「稼ぐ」ためのGo/No-Go基準（Minimum）

Go 条件

  • Preflight合格（Testnet）。
  • p99 SLOを 24h連続 満たす（req→ack <250ms、cancel <300ms）。
  • アラート・Runbookの 発火→対応→復旧 を演習済み。
  • Canary 1–2%で リジェクト <1%、error-sim なしでCIRCUIT OPENが発生しない。

No-Go 条件

  • short_error_total の上昇継続、CIRCUIT OPENが断続的に発生。
  • p99がSLO超過を連発（>10分/日）。
  • 収益系メトリクス未整備で効果測定不能。

いま走ると良いコマンド（最短）

# 共有DIRクリア
export PROMETHEUS_MULTIPROC_DIR=/tmp/bsb_mp
rm -rf $PROMETHEUS_MULTIPROC_DIR && mkdir -p $PROMETHEUS_MULTIPROC_DIR

# metrics 公開（reader）
PYTHONPATH=src METRICS_ENABLED=true METRICS_PORT=9523 \
PROMETHEUS_MULTIPROC_DIR=/tmp/bsb_mp python -m src.cli metrics-serve &

# p99用の計測（writer）
for i in {1..30}; do
  PYTHONPATH=src METRICS_ENABLED=true PROMETHEUS_MULTIPROC_DIR=/tmp/bsb_mp \
  python -m src.cli engine-dryrun --symbol BTCUSDT --hold 1 --bypass-canary >/dev/null 2>&1
done

# ヒストグラム確認
curl -s http://127.0.0.1:9523/metrics | grep -E 'short_req_ack_ms_|short_cancel_ms_' | head

まとめ

  • 基盤は整った（安定公開・観測・安全柵・性能土台は◎）。
  • いまの最重要は：①p99実測の確実化 → ②アラート実弾確認 → ③Testnetの超低比率Canary開始。
  • その先は 収益ダッシュボード と 戦略の当たり前品質（発注品質×スリッページ×手数料）を回すだけ。

-Bot, CEX, DEX, 開発ログ