🛠️開発記録#217 (2025/5/11) MMBot 開発ログ 21「デバッグ高速化とリアルタイム計測の導入」

前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。

本稿は、暗号資産マーケット‐メイカー Bot（以下 MMBot）を Docker 環境で運用する際に遭遇した 「ログが出ない／接続箇所が特定できない」 問題を、最短で切り分けるまでの開発メモを整理したものです。
売買ロジックや実運用パラメータは伏せ、公開してもエッジを損なわない範囲の“開発ノウハウ”だけを共有します。

環境依存の落とし穴と対策

段階的な接続ヘルスチェック

① REST      : ping instruments-info         → OK?
② get_minQty: DBG before / after            → 数値取得?
③ WS connect: DBG before / after            → ハンドシェイク通過?
④ orderbook : HDLR ERR 例外ログ             → パース成功?

REST → WS → パーサ の順に「パイプの詰まり」を潰すと、再現性のあるデバッグ手順になります。

計測用 METRIC 行の設計

10 秒間隔で 運用に直結しない抽象値 だけを残すことで、安全に統計が取れます。

METRIC spr_pct=<%>  spr_ticks=<tick差>  notional=<USD>  loop_ms=<ms>

• パラメータ (<%>, <USD>) は範囲化 or 正規化して保存
• loop_ms でボトルネック（DB I/O や API レイテンシ）を即検知

開発ログから得た学び — 2 時間のタイムライン

今後の改善 TODO

おわりに

今回のアップデートで 実行パイプラインの見える化 と 計測フレーム が整備されました。これにより、次フェーズの パラメータ最適化 を 「勘」ではなくデータドリブン で進められます。
同じ問題に悩む開発者の参考になれば幸いです。

👇ラジオで話したこと

きょうは 「MMBotを“静かに”24 時間まわすためのデバッグ＆リアルタイム計測テク」 がテーマです。ポイントは ①.env→tpl→json の安全な設定パイプライン、②Makefile １行で Mainnet／Testnet を切り替える運用フロー、③Loguru で WARN だけ を抽出して tail 監視するログ設計、④スプレッドが狭い市場では「Fill 0 = 成功」と腹をくくるリスク管理、の 4 本柱です。

1. なぜ「静かな 24 h 監視」が必要？

• Mainnet 最小ロット（0.0001 BTC）でまず 1 bps だけ差し込むと、板が詰まっている日は 注文が一度も約定しない ことがあります。
• しかしこの “Fill 0” は 損しない という意味で成功シナリオ。— 市場が開くまで待てる「我慢強さ」を Bot 側で担保しておくわけです。 SQL Easy

2. .env → tpl → json の安全パイプライン

1. .env.prod に API キーやロットサイズを保存。
2. config_mainnet.tpl に ${BYBIT_KEY_MAIN} のようなプレースホルダを書く。
3. Makefile で

envsubst < config_mainnet.tpl > config_mainnet.json

 — envsubst はシェル組込みではなく GNU gettext に付属するコマンドで、環境変数を一括展開します。 Stack Overflow
4. 生成後はすぐ .gitignore に入っているか確認し、rm -f で掃除。

3. Makefile ワンライナー運用

ENV ?= .env.test   # “?=” は「未定義なら代入」の意
run: $(CONFIG)
	set -a && source $(ENV) && set +a && \
	docker compose run --rm --entrypoint "" $(SERVICE) \
		python -m MMbotbybit.MMbotbybit \
		--lot $(LOT) --max_loss_usd $(LOSS)

• set -a (セット・ハイフン・エー) は 「読み込んだ変数をすべて export」 の意味。 Stack Overflow
• ENV=.env.prod make run と打てば 後勝ち ルールで .env.prod が優先されます。

4. Loguru で WARN だけを追う

logger.add("logs/warn.log",
           level="WARNING",
           rotation="10 MB",
           enqueue=True)
logger.add(lambda m: print(m, end="", flush=True), level="DEBUG")

• flush=True を付けないと DEBUG が バッファに溜まって Docker logs に流れません。 LoguruReal Python
• 端末では tail -F logs/warn.log。-F は “ファイル名の切替えも追従” の略なので、ローテーション後も自動で追い続けます。 prefetch.net

5. リアルタイム計測用 METRIC 行

METRIC spr_pct=0.12 spr_ticks=3 notional=24 loop_ms=87

• 10 秒おきに “抽象値” だけを残し、個別約定情報は書かないので流出リスクが低い。
• loop_ms が 500 ms を超えたら DB I/O やネット遅延を疑う。ログ設計の基本は「まず可視化，後で最適化」 です。 Better Stack

6. 24 h ランで詰まったポイント & 直し方

7. 今日の学び

1. “何もしない” もテスト — スプレッドが狭い日はマッチしないのが正解。
2. ログレベル分離 は tail × flush で 90 % 片付く。
3. 環境変数を数字にする と JSON 生成エラーが減る。
4. 小さいコミットを刻む と git revert で 10 分ロールバックが可能。 Stack Overflow

一言用語解説

最後まで聞いてくださってありがとうございました。
それではまた次回の放送でお会いしましょう。よだかでした。