OpenClaw Gateway の導入はスタート地点にすぎず、本番で当番時間を食うのは ヘルスチェックの取り違え、ログが見つからない、アップグレード後の設定ドリフト です。本文は Linux systemd + Tunnel、Docker Compose、三環境インストール を終えたチーム向けに、最小観測面、ログの取り回し、アップグレード／ロールバック、症状対照表 を補います。ルーティング方針は modelRouting 記事 へ続けてください。
インストール手順はハッピーパスを証明しますが、本番では プロセスの見かけ上の生存、ポート競合、権限の変化、下流モデルのタイムアウト などの長尾に当たります。以下の六つは、当番を推測から検証へ戻す入口です。
ヘルスチェックが緩すぎる： プロセスの有無だけを見て Gateway が実際にルーティングしているかを確認せず、トラフィックを流してから半壊に気づく。
ログが分散： systemd、コンテナ、アプリの標準出力、リバースプロキシが別々に書き、障害時に時系列がつながらない。
アップグレードに基準がない： 前のイメージ digest や npm グローバル版を覚えておらず、ロールバックが「入れ直して祈る」になる。
設定と秘密情報の混在： openclaw.json と環境変数注入がずれ、間欠的な 401 やルーティングの静かな失敗になる。
観測と変更の非同期： 待ち受けアドレスや Tunnel の宛先を変えたのに、監視のプローブパスを更新しない。
Gateway を万能実行機にする： 重い Xcode 作業を同じ小型 VPS に載せ、CPU が張り付いたあと「モデルが遅い」と誤認する。
二つ以上当てはまるなら、まず 最小観測面 を埋めてから機能を積み上げないと、リリースのたびに同じ種類の障害で学費を払い続けます。
表で役割を分け、「入れられる」と「安定して回せる」を同じレビューに混ぜないようにします。
| テーマ | インストール／常駐記事（systemd・Docker・三環境） | 本文（本番観測と変更） |
|---|---|---|
| プロセスと露出面 | unit／Compose、ループバック待ち受け、Tunnel またはファイアウォール方針 | 生存プローブ、ポート衝突の巡回、変更後のプローブパス回帰 |
| 設定モデル | 初回の openclaw.json 書き込み、ディレクトリ権限 | diff レビュー、バックアップ、カナリアとロールバック順序 |
| ログ | まずディスクに残るか journal／docker で集めるか | フィールドの意味、相関 ID、よくあるエラー型の整理 |
| アップグレード | コピペ可能な更新コマンドまたはイメージ取得パスを示す | digest／版の記録、バックアップ地点、ロールバック検証リスト |
| モデルルーティング | 任意で触れる程度 | 深い方針は modelRouting 専用記事へ |
運用の再現性は、担当者の記憶ではなく「同じ確認コマンドと同じロールバック順」から生まれます。
順序は systemd と Docker の両方に合います。まず 事実層（プロセス／ポート／ヘルスエンドポイント）、次に 解釈層（ログと下流）。コマンドはディストリで多少違っても、チェックポイントは揃えてください。
主プロセスの確認： systemd は systemctl status、Docker は docker compose ps。再起動回数と終了コードを見る。
待ち受けの突合： ss -lntp またはコンテナのポートマッピングが Tunnel／リバプロの宛先と一致するか。
ヘルスチェック： ドキュメントまたは自前のプローブパスへ HTTP プローブを当てる。「プロセス起動」と「ルーティング可能」を分ける。
直近ログの取得： journalctl -u または docker compose logs --tail=200。時間窓を決めてから全文検索する。
下流モデルの検証： 最小のリクエストで「Gateway は正常だが上流 API がおかしい」を切り分ける。
変更記録の出力： リリースごとに版／digest、設定 diff、プローブ結果を残し、次の当番が続けられるようにする。
# 例：クイック巡回（unit／コンテナ名は置き換え） systemctl status openclaw-gateway.service --no-pager || true ss -lntp | grep -E '18789|LISTEN' || true # Docker 側（例） # docker compose -f /opt/openclaw/docker-compose.yml ps # docker compose -f /opt/openclaw/docker-compose.yml logs --tail=200 gateway
ヒント： Cloudflare Tunnel を使う場合、変更後は 外向きのプローブ と ホスト上のループバック プローブ の両方を確認し、エッジに古いルートが残って「内側だけ通る」誤判定を避けてください。
ロールバック可能なアップグレード には三つが要ります。リリース前のスナップショット、リリース中は変更ベクトルを一つに絞ること、リリース後は同じプローブ集合で受け入れ確認することです。Docker では digest 固定 またはプライベートレジストリのタグ運用を優先し、ベアメタル／npm では グローバルパッケージの版 と lockfile（該当する場合）を固定します。
カナリアの考え方：ステージングまたは低トラフィックのレプリカで先に検証し、本番へ段階的に広げる。Gateway の背後にリモート実行ノードがあるなら 層別リリース で、まず制御面を確かめてから実行面を広げる。
注意： openclaw.json と環境注入をバックアップせずに「ついでにルートも触る」並行作業は避けてください。本番で最も多い停止要因は設定の半適用状態です。
以下の数値はレビューで揃えるための経験則のオーダーです。実際のタイムアウトとクォータはベンダーと契約に従います。
| 症状 | まず疑うこと | 対応の方向 |
|---|---|---|
| 起動直後に終了 | 設定 JSON の文法、環境変数不足、ポート占有 | フォアグラウンドで一度再現し、インストール記事のチェックポイントと照合 |
| 間欠的な 401 | 鍵ローテの非同期、複数の設定ファイルパス | 注入元を一本化し、古い shell プロファイル汚染を掃除 |
| CPU が長時間張り付く | 実行負荷を Gateway と同機に積んでいる | 重い作業を専用実行ノードまたはリモート Mac へ移す |
| 遅延の急増 | 下流のレート制限、DNS、TLS ハンドシェイク | ログとキャプチャを層別にし、ネットワークを切り分けてからモデルへ手を入れる |
重い macOS ビルド、署名、GUI 依存の作業を Gateway と同じ小型 Linux VPS に載せるのは短期的には楽ですが、制御面の安定性とトラブルシュート時の S/N 比 を同時に落とします。純ローカルのノートだけでは 24 時間体制と監査可能な隔離も難しい。安定した iOS CI、自動化エージェント、契約で縛れる算力 が要るチームは、Gateway は汎用 VPS に置き、macOS 実行は 専用のリモート Mac ノード に載せるのが安全です。運用境界と伸縮の両面で、NodeMini のクラウド Mac Mini レンタル はその実行層に向きます。リージョンとディスクでノードを選び、OpenClaw 制御面と層を分け、当番は明瞭な観測面だけを見ればよくなります。
ブログ一覧で OpenClaw カテゴリ を絞り込み、systemd → Docker → 観測 → modelRouting の順で読んでください。
ヘルプセンター を参照し、続けて本文のヘルスチェックとログの章と突き合わせてください。