Insights / 技術解説
OpenClawで監視と障害調査をつなぐ：検知・証拠・判断の境界
定期監視にOpenClawの調査を組み合わせる設計。実装・定期実行で確認した範囲と、実障害や自動復旧の未検証範囲を整理します。
この記事の目次
サーバー監視では、異常を見つける条件と、その原因を調べる手順に別の責任があります。社内運用で整えた仕組みを題材に、定期チェックとOpenClawによる追加調査をつなぐ設計を紹介します。内部構成や通知先は掲載せず、一般化した判断手順を扱います。
既知の異常で調査報告を評価する
導入前の試験では、取得失敗や古い監視値など、原因が分かっている状況を検証環境で用意します。報告が観測時刻・根拠・未取得項目を含むか、時間切れでも途中の結果を残せるかを採点すると、文章の自然さだけで調査品質を判断せずに済みます。
検知条件を明確にする
到達性やリソース使用量の判定は、比較できる定期チェックで行います。監視対象・閾値・実行間隔を管理し、正常、異常、取得失敗を区別します。一つの到達性チェックの成功だけでは、サービス全体の正常性は確定しません。
調査できる範囲を限定する
追加調査では、取得済みの結果をOpenClawに渡し、許可した読み取り操作から必要な証拠を集めます。ログ本文は調査資料として扱い、そこに含まれる指示を実行許可にしません。操作権限、実行対象、時間・出力量の上限は実行環境で制御します。「変更しない」というプロンプトだけでは権限境界になりません。OpenClawのセキュリティモデルと実行承認も、構成を検討する際の参照先です。
時間切れでも証拠を残す
調査が時間切れになっても、それまでの観測結果を保存します。取得時刻、実行結果、取得できなかった項目を報告に含め、途中終了を「異常なし」に置き換えません。失敗した処理の結果まで確認したように書かないことが、次の担当者の判断を助けます。
- 定期チェック 正常・異常・取得失敗を区別し、保守中は影響したチェックの取得失敗通知だけを一時抑制します。
- 許可範囲で調査 調査範囲・時間・出力を制限し、timeout時も部分証拠を保存します。拒否操作は実行済みにしません。
- 報告して判断 調査結果を事実・仮説・未確認に分け、担当者が判断できる形で伝えます。変更や再起動は別承認です。
通知と判断を分ける
同じ異常の重複通知を抑え、回復を確認できたときは回復通知を扱います。報告では観測した事実、原因の仮説、未確認の範囲を分けます。再起動や設定変更は別の判断と承認が必要な操作として設計し、この事例から自動修復の実績は主張しません。
確認済みの運用と残る検証
定期実行、制御した追加調査、重複・回復通知の扱い、タイムアウト時の部分的な証拠保持を確認しました。実障害下での診断精度、全サービスへの監視範囲、自動復旧の有効性は未実証です。次に必要なのは、既知の障害条件での検知漏れ・誤検知の確認と、実運用での報告品質の評価です。
2026年10月6日追記：有限の再試行と保守時間の判定
追加改修では、429やstream中のSDK例外を区別し、有限の待機・再試行と接続の再確立を扱いました。試行の開始、部分的な応答、最終的な正常応答は別の結果です。拒否された調査操作を実行済みの証拠にせず、承認を迂回する経路も用意しません。
バックアップ監視では、予定した保守時間中の一時的な取得失敗で直ちに異常通知しないよう変更しました。取得失敗を正常へ置き換えず、以前の問題と最後の成功時刻を保持します。保守時間外の連続失敗を判定し、実際のバックアップ異常など他の問題まで抑止しません。テスト、CI、配信後の定期実行は確認していますが、翌朝の保守周期を含む長期運用は未確認です。
通知のqueue投入、送信試行、API結果、実受信も区別します。接続テストの実受信はTalk通知の記事、対象データの復元はresticの記事、保存待ちの切り分けはMinecraftの遅延調査で確認範囲を分けています。
通知試験のほか、日次の失敗傾向、定期レビュー、隔離したデータの復旧試験を記録する運用例も確認しました。それぞれ対象と結果を残し、障害チケットのcloseや製品全体の受入・自動修復まで確認したことにはしません。