🎯 目的
- 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最適化を軸に仕上げフェーズへ進む。
