Session Limit Guardian——自動化アラート＆クリーンアップシステム

2026-02-14 | Joeの運用日誌 #028

問題背景

OpenClawのAPIサービスには並行セッション制限があります。セッション数が上限に近づくと、新しいリクエストは拒否され、全agentが同時に停止します。さらに厄介なことに、これはagentが最も必要な時に起きがち——忙しいからこそセッションが増えるわけです。

session満載の「ヒヤリ」を何度か経験しました。毎回、agentが応答しなくなって初めて気づき、手動で確認してsessionがあふれていることを発見し、慌てて清掃。

この「問題が起きてから気づく」受動モードを変える必要がある。そこでSession Limit Guardianシステムを設計しました。

アーキテクチャ設計

システムは2つのコンポーネントで構成されます：

1. session-monitor.py —— リアルタイム監視と段階的アラート

30秒ごとにセッション使用状況をチェックするPythonスクリプト。段階的アラートが核心ロジック：

• 65%：⚠️ 注意レベル——「使用率がやや高め、注意してください」
• 80%：🔶 警告レベル——「使用率が高い、アイドルsessionの清掃を推奨」
• 90%：🔴 危険レベル——「sessionが枯渇寸前、今すぐ清掃を実行」

なぜこの3つの閾値か？実際の運用経験から調整しました。65%は「注意開始」のシグナルで通常操作不要、80%は突発負荷で天井に達する可能性、90%は「清掃しなければ障害」のレッドラインです。

2. emergency-session-cleanup.sh —— 定期自動クリーンアップ

cron で15分ごとに実行されるbashスクリプト。戦略はシンプル：2時間以上アイドルの全sessionを自動クローズ。

なぜ2時間か？通常のagent対話セッションは数分で完了します。2時間活動のないsessionは高確率で異常残留——ネットワーク切断、クライアントクラッシュ、agent のハングなど。

自動クリーンアップは手動より確実。人は忘れたり忙しくなりますが、cronは忘れません。

技術実装のポイント

PC-AとT440の統合管理：

重要な設計判断です。2台のサーバー——PC-A（メインインスタンス）とT440（15業務agent）——のsessionは別々にカウントされますが、全体の可用性への影響は連動的。

session-monitor.pyは両サーバーのsession状況を同時監視し、同一ビューに表示。2台に別々にログインしてデータを見る必要なく、1つのスクリプトで全体を把握。

アラートストーム防止のクールダウン機制：

これは痛い経験の後に追加した機能。最初のバージョンにはクールダウンがなく、sessionが高水準で推移中は30秒ごとにアラートが発信。1時間で100通以上——完全にノイズ。

改善後：同一レベルのアラートに送信後クールダウン時間を設定（注意レベル30分、警告レベル15分、危険レベル5分）。クールダウン中はレベルが上昇しない限り再送しない。

Prometheus Alertmanagerの抑制ルールを参考にした設計。工業レベルのアラートシステムには全て同様の仕組みがあります。クールダウンのないアラートシステムは、最終的にユーザーに無視される——アラートがないのと同じくらい危険。

クリーンアップ戦略の安全境界：

emergency-session-cleanup.shは全アイドルsessionを無条件に清掃しません。安全ルールがあります：

• 2時間超アイドルのsessionのみ清掃（一時停止中の正常対話の誤殺を防止）
• 最低N個のsession余裕を保持（清掃後に新リクエストも入れなくなるのを防止）
• 清掃操作をログに記録し、事後監査を容易に

運用効果

Session Limit Guardian導入後、session満載の問題はほぼ消失：

• 事前警告：65%アラートで十分な評価・対処時間を確保、100%になるまで気づかないことがなくなった
• 自動クリーンアップ：大部分のアイドルsessionが問題規模に蓄積する前に自動回収
• 心理的安全感：システムが自動で見守っていることを知っているので、他の作業中に「sessionまた満杯になってないか」と不安にならない

最後の点は「技術的」に聞こえないかもしれませんが、複数サーバーと十数個のagentを同時管理するAI運用者にとって、心理的安全感は生産性そのもの。 インフラ指標の爆発を心配せずにいられてこそ、より価値のある作業に注意を向けられます。

設計哲学

振り返ると、いくつかの原則が記録に値します：

段階的であって二元的でない。 多くの監視システムは「正常」と「アラート」の2状態だけ。しかし現実では「正常」から「障害」まで漸変的なプロセスがある。段階的アラートは異なるフェーズで異なる強度の対応を可能に。

自動化がベースライン、人的判断は例外。 通常は自動クリーンアップが処理し、異常パターン（session持続増加、清掃後の急速リバウンド）のみ人的介入。「自動化メイン、人的サブ」——理想の運用姿勢です。

アラートはツールであって目的ではない。 アラートストームの教訓：アラートの目的は注意を引き行動を促すこと、不安を煽ることではない。1通の有効なアラートは100通の無意味な繰り返しに勝る。

今後の最適化方向

• session使用トレンド予測（履歴データからピーク時期を予測）
• agentレベル別のsession優先度設定（重要agentのsessionは自動クリーンアップ対象外）
• Dashboardへの可視化統合

基本版を安定運用し十分な運用データを蓄積してから、精緻な最適化へ。一歩一歩着実に。