Bot mmnot 開発ログ

🛠️開発記録#242(2025/6/4)Cron & Docker自動再起動・停止:取り組みと学びのまとめ

🎯 目的

  • Botが沈黙・フリーズ・ログ出力停止したときに自動的に検出し、Slack通知を出す
  • 必要に応じて再起動 or 停止を自動で行う
  • それらの定期監視を Cron に組み込む

✅ 実施した取り組みと到達点

1️⃣ watchdog.sh の設計と実装

  • 主な監視機能
    • logs/MMBot.log の更新が止まっていないか(タイムスタンプ差分を pnl_age として計算)
    • pnl_report.csv の最終更新が古すぎないか
    • Slack へのエラー通知機能(Webhook)
  • 安全制御ラップを実装済み
    • docker compose restart mmbot を直接叩かず、DRY-RUNラッパーで包んで事故防止
    • --dry-run モードでSlack通知だけを行う検証ルートも搭載済み
    • .env.production.env.testnet から環境変数を読み込む仕組みを内包
  • Slack通知の分離も設計済み(watchdog用とBot本体通知用を分離)

2️⃣ Cronへの登録と動作確認

  • crontab -e に以下を追加(1分おき監視の例)
* * * * * /path/to/MMBot/scripts/watchdog.sh >> /path/to/MMBot/logs/watchdog_cron.log 2>&1
  • 動作確認済み
    • .log.csv の最終更新時刻が古くなるとSlackにアラート通知
    • 再起動モードでは docker compose restart mmbot が発火されることを確認済み

3️⃣ Docker側の自動再起動ポリシーとの重複問題も検討

  • docker-compose.yml に以下を設定済み
restart: "${MMBOT_RESTART:-unless-stopped}"
  • これにより Botがクラッシュやexitした場合に自動再起動される
    → watchdogと併用することで、Docker Restart(起動失敗時)+watchdog(沈黙時)という二重の冗長化体制が形成される

⏸ 保留中の内容と理由

保留内容理由解決の方向性
✅ Cronジョブの運用レベルでの安定化crontabの書き方や環境変数の読み込みなどに多少の混乱あり.env の明示的読み込み (source .env && watchdog.sh) をスクリプト内で吸収するように改善予定
watchdog_cron.logログ肥大化無限追記になってしまう可能性logrotatemax lines 制御の導入を検討中
Slack通知がややノイジーになる可能性毎分Slackが鳴る設定だと本番運用では過剰通知に初期フェーズは通知だけ、後でフィルタ条件追加予定(失敗3回連続で通知など)
docker stopwatchdog.sh役割整理両方で「停止」を制御しようとすると意図しない挙動になる可能性明確に役割分担:Docker Restart → 異常停止復旧、watchdog → ロジック停止やフリーズ検出
✅ Self-hosted Runner連携によるGithub Actions失敗時の自動停止Actions失敗とBotの自動停止をどう結びつけるか設計中runner_healthcheck.ymldocker stop mmbot を仕込む設計を検討中

💡 学びと設計上の気づき

学び説明
Dockerと外部監視は補完関係であるべきDockerのrestartは「プロセスが死んだら起動」だが、watchdogは「生きてるが止まってる」を検出できる
.envの読み込みはスクリプト内で完結するべきCronではシェルが独立して起動されるため、グローバルにsourceしても反映されない
--dry-run での検証は爆発防止に必須実環境でいきなり再起動させず、通知やログだけで挙動を確認できるのは大きな安心材料
Slack通知はフェイルセーフ設計に近い通知が止まったら異常、通知が多すぎても異常。運用バランスを取る工夫が必要

🔜 今後の方向性

  • watchdog.sh の通知条件(失敗カウント・再起動判定)を微調整
  • runner_healthcheck.ymldocker stop mmbot を統合し、CIエラー時の自動停止を組み込み
  • .env.production.exampleSLACK_WEBHOOK_WATCHDOGLOG_FILE などを追記して汎用化
  • watchdog_cron.log のサイズ制御 or ログローテート導入
  • scripts/run_watchdog.sh などのCronラッパーを整備して、可搬性の高い監視体制をテンプレート化

🔖 まとめ

目的だった「Botがフリーズしても検出してSlack通知する」ためのwatchdog+cron構成はほぼ完成し、あとは細部の安定化と運用設計を残すのみ
構造面でも「Docker restart=プロセス死の冗長性」「watchdog=論理死の検出」という役割分担が定義され、今後はCI統合とSlack最適化を軸に仕上げフェーズへ進む。

-Bot, mmnot, 開発ログ