🎯 目的
- 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 のログ肥大化 | 無限追記になってしまう可能性 | logrotate や max lines 制御の導入を検討中 |
✅ Slack通知がややノイジーになる可能性 | 毎分Slackが鳴る設定だと本番運用では過剰通知に | 初期フェーズは通知だけ、後でフィルタ条件追加予定(失敗3回連続で通知など) |
✅ docker stop と watchdog.sh の役割整理 | 両方で「停止」を制御しようとすると意図しない挙動になる可能性 | 明確に役割分担:Docker Restart → 異常停止復旧、watchdog → ロジック停止やフリーズ検出 |
✅ Self-hosted Runner連携によるGithub Actions失敗時の自動停止 | Actions失敗とBotの自動停止をどう結びつけるか設計中 | runner_healthcheck.yml に docker stop mmbot を仕込む設計を検討中 |
💡 学びと設計上の気づき
学び | 説明 |
---|
Dockerと外部監視は補完関係であるべき | Dockerのrestartは「プロセスが死んだら起動」だが、watchdogは「生きてるが止まってる」を検出できる |
.env の読み込みはスクリプト内で完結するべき | Cronではシェルが独立して起動されるため、グローバルにsource しても反映されない |
--dry-run での検証は爆発防止に必須 | 実環境でいきなり再起動させず、通知やログだけで挙動を確認できるのは大きな安心材料 |
Slack通知はフェイルセーフ設計に近い | 通知が止まったら異常、通知が多すぎても異常。運用バランスを取る工夫が必要 |
🔜 今後の方向性
watchdog.sh
の通知条件(失敗カウント・再起動判定)を微調整
runner_healthcheck.yml
に docker stop mmbot
を統合し、CIエラー時の自動停止を組み込み
.env.production.example
に SLACK_WEBHOOK_WATCHDOG
、LOG_FILE
などを追記して汎用化
watchdog_cron.log
のサイズ制御 or ログローテート導入
scripts/run_watchdog.sh
などのCronラッパーを整備して、可搬性の高い監視体制をテンプレート化
🔖 まとめ
目的だった「Botがフリーズしても検出してSlack通知する」ためのwatchdog+cron構成はほぼ完成し、あとは細部の安定化と運用設計を残すのみ。
構造面でも「Docker restart=プロセス死の冗長性」「watchdog=論理死の検出」という役割分担が定義され、今後はCI統合とSlack最適化を軸に仕上げフェーズへ進む。