前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
対象読者:
VSCode で Python を書き始めたばかり / Docker・Git をこれから触る 初心者の方向け。
「まず動く」「まず安全」のために、きょう私が実装した 超 小さな改善を共有します。
この記事で学べること
- ログレベルって何? ──
INFO
とWARNING
を分ける理由 - Loguru + Makefile で warn.log を 1 行で分離する手順
- logging_setup.py パターン──“設定は import だけで完了” の作り方
- .gitignore の拡張&小さいコミットで安全に push する流れ
1. なぜ「警告ログだけ」切り出したいの?
シーン | 起こりがちな困りごと |
---|---|
Bot が静かに止まっていた | 5000 行の DEBUG ログに WARN が埋もれていた |
デプロイ後に Slack が警告まみれ | INFO も WARNING も同じチャンネルに投げていた |
ログを tail していたら 重要行だけ流れた | rotation でファイルが切り替わり tail -f が外れた |
対策:「WARN 以上だけを 専用ファイル に書き、
tail -F
で常時監視する」
2. Loguru で warn.log を 1 行追加
2-1. logging_setup.py(新規ファイル)
from pathlib import Path from loguru import logger LOG_DIR = Path("/app/logs") LOG_DIR.mkdir(parents=True, exist_ok=True) logger.remove() # 既定ハンドラを解除 logger.add(lambda m: print(m, end="")) # 標準出力 (全レベル) # ★ WARN 以上だけ logger.add( LOG_DIR / "warn.log", level="WARNING", # ←ここがポイント rotation="10 MB", retention="30 days", compression="zip", format="{time:YYYY-MM-DD HH:mm:ss,Asia/Tokyo} | {level} | {message}", enqueue=True, ) # 通常ログ(DEBUG〜INFO も含む) logger.add( LOG_DIR / "mm_bot_{time:YYYYMMDD_HHmmss}.log", rotation="00:00", retention="7 days", compression="zip", enqueue=True, )
2-2. Bot 本体に 1 行だけ追加
import MMbotbybit.logging_setup # ← import するだけでロガー登録完了
※ # noqa: E402,F401
を付ければ Linter 警告をスルーできます。
3. Makefile に tail エイリアスを 2 行
logs-warn: @tail -F logs/warn.log .PHONY: logs-warn
使い方
make logs-warn # これだけで WARN が流れる
ログローテーションが走っても
tail -F
ならファイル切替えを追従してくれるので安心。
4. .gitignore を広げて“秘密”と“ゴミ”をブロック
# --- Runtime logs --- *.log logs/ # --- Secrets --- slack_config.json .env.* # --- Generated configs --- config_*net.json # --- Backups / scratch --- *.bak MMbotbybit/*check*.py
Git 完全初心者メモ
コマンド | 意味 |
---|---|
git add <file> | スナップショット候補に載せる |
git commit -m "msg" | 候補を 1 つの履歴に固める |
git push origin main | GitHub にアップロード |
きょう私が打った実コマンド:
git add MMbotbybit/logging_setup.py MMbotbybit/MMbotbybit.py Makefile git commit -m "feat: move logging to logging_setup" git push origin main
5. 動作確認(3 行で終わり)
make logs-warn & python MMbotbybit/MMbotbybit.py --mode testnet --max_cycles 2 # → タイムアウトや max_cycles 超過で WARNING が流れたら成功!
表示例:
2025-05-07 10:12:34 | WARNING | wait_for_fill timeout → cancel 12345
6. きょうの学び・まとめ
学び | 初心者に刺さる要点 |
---|---|
ログレベル | INFO=通常情報、WARNING=要注意、ERROR=致命的 |
専用ログファイル | フィルタリングは logger.add(..., level="WARNING") 1 行で完了 |
設定の“副作用 import” | import logging_setup だけで全スクリプトが同じログポリシーを共有 |
小さいコミット | 1 タスク → 1 コミット → 1 push がデバッグ最短ルート |
.gitignore 拡張 | ログと秘密鍵は “書かない” 文化を最初に身につける |
次の一歩(明日の To-Do)
pytest
導入 → テストが 0 件でも緑で動く状態をまず作る- GitHub Actions に
pytest
とgitleaks
を貼って 自動スキャン - README に “Quick Start” を 10 行だけ追記して、誰でも回せる形へ
「ログで事故を見逃さない」 たった 1 行の追加が、夜中のアラート対応のスピードを一段引き上げてくれます。
みなさんも “まず警告ログだけ切り出す” から始めてみてください!
👇ラジオで話したこと
🎙️ 開発ラジオ #212:Loguru × Makefile で警告ログをリアルタイム監視!
こんにちは、仮想通貨bot開発ラジオへようこそ!今回は、仮想通貨Bot「MMbot」の開発ログ第18回として、LoguruとMakefileを活用した警告ログのリアルタイム監視手法についてお話しします。特に、VSCodeでPythonを始めたばかりの方や、Docker・Gitにこれから触れる初心者の方に向けて、実践的な改善ポイントを共有します。
🔍 なぜ「警告ログだけ」を切り出すのか?
開発中、Botが静かに停止していたり、デプロイ後にSlackが警告まみれになった経験はありませんか?これらの問題の多くは、ログが適切に管理されていないことに起因します。例えば、5000行のDEBUGログに重要なWARNINGが埋もれていたり、ログローテーションでtail -fが外れてしまったりすることがあります。
そこで、**「WARNING以上のログだけを専用ファイルに書き出し、tail -Fで常時監視する」**という対策を取りました。これにより、重要な警告を見逃すことなく、リアルタイムで対応が可能になります。
“キーワード早わかり” コーナー
――まずは 5 分で押さえる用語集――
ワード | 一言イメージ | ざっくり説明 |
---|---|---|
tail -F | 「ずっと最後をのぞき見」 | ファイルの末尾を表示し続け、ローテーションでファイル名が変わっても追跡 (-F =Follow name)。Linux の標準監視ワザ。Linux.com Super User ITプラットフォームドキュメント |
エイリアス(alias) | 「コマンドのあだ名」 | alias gs='git status' のように長いコマンドを短縮。毎回打つ手間をゼロにできる シェルのニックネーム機能。IBM - United States GNUmath.uh.edu |
Loguru(ログル) | 「Pythonログの時短ツール」 | from loguru import logger だけで高機能ロガーが即使える。標準 logging の設定地獄を解消するライト級ライブラリ。loguru.readthedocs.io Better Stack loguru.readthedocs.io |
warn.log | 「黄色信号だけ集める箱」 | ログレベル WARN 以上(WARN/ERROR/CRITICAL)だけを書き出した専用ファイル。不具合の予兆を可視化。 Better Stack Stack Overflow Medium |
debug.log | 「虫メガネ用メモ帳」 | レベル DEBUG を含む全部入りの詳細ログ。変数値や内部フローを追いたいときだけ開く。 |
warn.log と debug.log の違い | 「緊急ベル vs. 日誌」 | - warn.log: “想定外だが動作継続” を即知らせる。運用監視向け。 - debug.log: コード内部を逐語記録。開発者がバグを再現・解析するための原本。レベル設定で同じログを別ファイルに“分流”できるのが Loguru の強み。 |
🎧 ここまでのポイント(30 秒まとめ)
- tail -F で WARN 専用ファイル をリアルタイムに張り込み。
- alias で長い
docker compose …
を “ワンキー呼び” に。 - Loguru を導入、
warn.log
とdebug.log
にレベル分離。 - こうして「静かな成功」と「響く失敗」を切り分ければ、
本番はスマホ通知だけで把握、開発は詳細ログで深掘り――二刀流の運用が完成します 🛠️
🛠️ Loguruでwarn.logを1行追加
まず、新規ファイルlogging_setup.py
を作成し、以下のように設定します:
from pathlib import Path from loguru import logger LOG_DIR = Path("/app/logs") LOG_DIR.mkdir(parents=True, exist_ok=True) logger.remove() # 既定ハンドラを解除 logger.add(lambda m: print(m, end="")) # 標準出力 (全レベル) # WARN以上のログを専用ファイルに出力 logger.add( LOG_DIR / "warn.log", level="WARNING", rotation="10 MB", retention="30 days", compression="zip", format="{time:YYYY-MM-DD HH:mm:ss,Asia/Tokyo} | {level} | {message}", enqueue=True, ) # 通常ログ(DEBUG〜INFOも含む) logger.add( LOG_DIR / "mm_bot_{time:YYYYMMDD_HHmmss}.log", rotation="00:00", retention="7 days", compression="zip", enqueue=True, )
Bot本体には、以下の1行を追加するだけで設定が適用されます:
import MMbotbybit.logging_setup # ← importするだけでロガー登録完了
これにより、全スクリプトが同じログポリシーを共有し、設定の一元化が図れます。
🧰 Makefileにtailエイリアスを2行追加
Makefileに以下のエイリアスを追加することで、警告ログの監視が簡単になります:
logs-warn: @tail -F logs/warn.log .PHONY: logs-warn
使い方は簡単です:
make logs-warn # これだけでWARNが流れる
tail -F
を使用することで、ログローテーションが発生してもファイルの切り替えを自動で追従してくれるため、安心して監視を続けることができます。
🧹 .gitignoreを広げて“秘密”と“ゴミ”をブロック
Gitリポジトリに秘密情報や不要なファイルが含まれないよう、.gitignore
を拡張しました:
# --- Runtime logs --- *.log logs/ # --- Secrets --- slack_config.json .env.* # --- Generated configs --- config_*net.json # --- Backups / scratch --- *.bak MMbotbybit/*check*.py
これにより、APIキーやSlackのWebhook URLなどの秘密情報が誤ってコミットされるリスクを軽減できます。
✅ 動作確認(3行で終わり)
以下のコマンドで、設定が正しく機能しているか確認できます:
make logs-warn & python MMbotbybit/MMbotbybit.py --mode testnet --max_cycles 2
実行後、warn.log
に以下のような出力があれば成功です:
2025-05-07 10:12:34 | WARNING | wait_for_fill timeout → cancel 12345
🧠 今日の学び・まとめ
- ログレベルの理解:INFO=通常情報、WARNING=要注意、ERROR=致命的
- 専用ログファイルの活用:
logger.add(..., level="WARNING")
で簡単に実現 - 設定の“副作用import”:
import logging_setup
だけで全スクリプトが同じログポリシーを共有 - 小さいコミットの重要性:1タスク → 1コミット → 1pushがデバッグ最短ルート
- .gitignoreの拡張:ログと秘密鍵は“書かない”文化を最初に身につける
🧭 次の一歩(明日のTo-Do)
- pytest導入:テストが0件でも緑で動く状態をまず作る
- GitHub Actionsにpytestとgitleaksを追加:自動スキャンでセキュリティ強化
- READMEに“Quick Start”を追記:誰でも回せる形へ
🎙️ おまけトーク:なぜ、わざわざ時間をかけてまでgit初期化に着手すべきだったのか?
Gitの初期化と適切な.gitignore
の設定は、プロジェクトのセキュリティと運用効率を高めるために不可欠です。APIキーや機密情報が誤ってリポジトリに含まれると、重大なセキュリティリスクにつながります。また、不要なファイルがコミットされると、リポジトリが肥大化し、管理が煩雑になります。初期段階でこれらを整備することで、将来的なトラブルを未然に防ぎ、安心して開発を進めることができます。
以上、開発ラジオ#212でした。また次回の放送でお会いしましょう!