Open WebUI の健全性を監視して維持する 🩺

Open WebUI インスタンスを監視することは、信頼性の高い運用、パフォーマンスの最適化、問題を迅速に特定・解決するために非常に重要です。このガイドでは、基本的な稼働確認から詳細なモデル応答テストまで、3つの監視レベルを解説します。

監視の理由:

• 稼働時間の確保: 停止やサービス障害を事前に検出します。
• パフォーマンスの洞察: 応答時間を追跡し、潜在的なボトルネックを特定します。
• 早期問題検出: 問題がユーザーに大きな影響を与える前に対処します。
• 安心感: Open WebUI インスタンスが順調に稼働していることを確認します。

🚦 監視のレベル

基本から詳細な監視まで、3つのレベルについて説明します:

1. 基本的な健康チェック: Open WebUI サービスが稼働して応答しているかを確認します。
2. モデル接続確認: Open WebUI が設定されたモデルに接続し、その一覧を取得できるかを確認します。
3. モデル応答テスト (詳細な健康チェック): モデルがリクエストを実際に処理し応答を生成できるかを確認します。

レベル1: 基本的な健康チェックエンドポイント ✅

最も簡単な監視方法は、/health エンドポイントをチェックすることです。このエンドポイントは認証不要で公開されており、Open WebUI サービスが正常に稼働している場合に 200 OK ステータスコードを返します。

テスト方法:

curl または任意の HTTP クライアントを使用してこのエンドポイントをチェックできます:

   # 基本的な健康チェック - 認証不要
   curl https://your-open-webui-instance/health

期待される出力: 成功した健康チェックは 200 OK の HTTP ステータスコードを返します。レスポンスボディの内容は基本的な健康チェックでは通常重要ではありません。

Uptime Kuma を使用した基本的な健康チェック 🐻

Uptime Kuma は、素晴らしくオープンソースで使いやすい、自分でホスト可能な稼働監視ツールです。Open WebUI を監視するのに非常におすすめです。

Uptime Kuma の設定手順:

1. 新しいモニターを追加: Uptime Kuma のダッシュボードで「Add New Monitor」をクリックします。
2. モニター設定を構成:
   • モニタータイプ: 「HTTP(s)」を選択します。
   • 名前: モニターにわかりやすい名前を付けます，例如「Open WebUI 健康チェック」。
   • URL: 健康チェックエンドポイントの URL を入力します: http://your-open-webui-instance:8080/health (アドレスとポートを実際の Open WebUI のものに置き換えてください)。
   • 監視間隔: チェック頻度を設定します (例: 60秒 毎分)。
   • 再試行回数: サービスをダウンとみなす前の再試行回数を設定します (例: 3回)。

このチェックで確認する内容:

• Webサーバーの稼働: Webサーバー (例: Nginx, Uvicorn) がリクエストに応答していることを確認します。
• アプリケーションの稼働: Open WebUI アプリケーション自体が稼働し、初期化されていることを確認します。
• 基本的なデータベース接続: アプリケーションがデータベースに接続可能であることを基本的に確認します。

レベル2: Open WebUI モデル接続 🔗

基本的な稼働確認を超えるには、/api/models エンドポイントを監視できます。このエンドポイントは認証が必要で、Open WebUI が設定されたモデルプロバイダー (例: Ollama, OpenAI) と正常に通信し、利用可能なモデルの一覧を取得できることを確認します。

モデル接続を監視する理由:

• モデルプロバイダーの問題: モデルプロバイダーサービスに問題がある場合 (例: API停止、認証失敗)。
• 設定エラー: Open WebUI 内のモデルプロバイダー設定のミスを特定します。
• モデルの利用可能性: 期待されるモデルが実際に Open WebUI によりアクセス可能であることを確認します。

APIエンドポイント詳細:

Open WebUI API ドキュメント を参照し、/api/models エンドポイントとそのレスポンス構造についての詳細を確認してください。

curl でのテスト方法 (認証済み):

このエンドポイントにアクセスするには API キーが必要です。以下の「認証設定」セクションを参照して API キーを生成する方法を確認してください。

   # 認証済みモデル接続チェック
   curl -H "Authorization: Bearer YOUR_API_KEY" https://your-open-webui-instance/api/models

(YOUR_API_KEY を実際の API キーに、your-open-webui-instance を Open WebUI のアドレスに置き換えてください。)

期待される出力: 成功したリクエストは 200 OK ステータスコードとモデル一覧を含む JSON レスポンスを返します。

API キー用認証設定 🔑

/api/models エンドポイントを監視する前に、Open WebUI で API キーを有効にし、生成する必要があります:

1. API キーを有効化 (管理者権限が必要):

   • 管理者として Open WebUI にログインします。
   • 管理設定（通常、右上のメニュー）> 一般 に移動します。
   • 「APIキーを有効にする」という設定を見つけて、オンにします。
   • 変更を保存 をクリックします。

2. APIキーを生成する（ユーザー設定）:

   • ユーザー設定（通常は右上のプロフィールアイコンをクリック）に移動します。
   • アカウント セクションに進みます。
   • 新しいAPIキーを生成 をクリックします。
   • APIキーに説明的な名前を付けます（例：「監視APIキー」）。
   • 生成されたAPIキーをコピー し、安全に保管してください。監視設定でこれが必要になります。

   (推奨, オプション): セキュリティのベストプラクティスとして、監視専用の非管理者ユーザーアカウントを作成し、そのユーザーのためにAPIキーを生成することを検討してください。これにより、万一APIキーが漏洩した場合の影響を限定できます。

   設定内にAPIキー生成オプションが表示されない場合は、Open WebUIの管理者に問い合わせて、APIキーが有効になっていることを確認してください。

Uptime Kuma を使用したモデル接続性監視 🐻

1. Uptime Kumaで新しいモニターを作成する:

   • モニタータイプ: "HTTP(s) - JSONクエリ"。
   • 名前: "Open WebUIモデ接続性チェック"。
   • URL: http://your-open-webui-instance:8080/api/models（これをあなたのURLに置き換えてください）。
   • メソッド: "GET"。
   • 期待されるステータスコード: 200。

2. JSONクエリを構成する（モデルリストを確認）:

   • JSONクエリ: $count(data[*])>0
     • 説明: このJSONataクエリは、API応答のdata配列（モデルリストを含む）内の要素が1つ以上あるかどうかを確認します。つまり、少なくとも1つのモデルが返されることを確認します。
   • 期待される値: true （クエリはモデルがリストされている場合にtrueを返すべきです）。

3. 認証ヘッダーを追加:

   • Uptime Kumaモニター設定の"Headers"セクションで"Add Header"をクリックします。
   • ヘッダー名: Authorization
   • ヘッダー値: Bearer YOUR_API_KEY（YOUR_API_KEYを先ほど生成したAPIキーに置き換えてください）。

4. 監視間隔を設定: 推奨間隔: 300秒（5分）またはそれ以上。モデルリストは通常それほど頻繁には変化しません。

代替JSONクエリ（高度な設定）:

特定のモデルやプロバイダーをチェックするために、より具体的なJSONataクエリを使用できます。以下はその例です:

• 少なくとも1つのOllamaモデルがあるかチェック: $count(data[owned_by=ollama])>0
• 特定モデル（例: gpt-4o）が存在するかチェック: $exists(data[id=gpt-4o])
• 複数の特定モデル（例: gpt-4oとgpt-4o-mini）が存在するかチェック: $count(data[id in [gpt-4o, gpt-4o-mini]]) = 2

これらのJSONataクエリが期待通りに動作することを確認するため、jsonata.org でサンプルAPI応答を使ってテスト・調整してください。

レベル3: モデル応答テスト（高度なヘルスチェック）🤖

最も包括的な監視を行うために、モデルが実際にリクエストを処理し応答を生成できるかどうかをテストします。これには、/api/chat/completionsエンドポイントへの簡単なチャット完了リクエスト送信が含まれます。

なぜモデル応答をテストするのか?

• エンドツーエンドの検証: APIリクエストからモデル応答まで、モデルパイプライン全体が機能していることを確認します。
• モデルの読み込み問題: 特定のモデルが読み込まれない、または応答しない問題を検出します。
• バックエンド処理エラー: モデルが完了を生成できない原因となるバックエンドのロジックエラーを捕捉します。

curlを使用してテストを実行する（認証付きPOSTリクエスト）:

このテストにはAPIキーが必要で、簡単なメッセージをchat completionsエンドポイントに送信します。

# モデル応答をテスト - 認証付きPOSTリクエスト
curl -X POST https://your-open-webui-instance/api/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d {
    "messages": [{"role": "user", "content": "HEALTHYという単語で返答してください"}],
    "model": "llama3.1",  # 使用可能と想定されるモデルに置き換えてください
    "temperature": 0      # 一貫した応答のため温度を0に設定
  }

(YOUR_API_KEY、your-open-webui-instance、そしてllama3.1を実際の値に置き換えてください。)

期待される出力: 成功したリクエストは200 OKステータスコードと、チャット完了を含むJSON応答を返します。応答に"HEALTHY"という単語（またはプロンプトに基づいた期待される応答）が含まれていることを確認します。

Uptime Kumaでレベル3の監視を設定するには、POSTリクエスト、JSON本文、認証ヘッダーを含むHTTP(s)モニターを構成し、応答内容を検証するJSONクエリを使用する必要があります。これは高度な設定であり、特定のニーズに応じてカスタマイズ可能です。

これらの監視レベルを実装することで、Open WebUIインスタンスの健全性、信頼性、パフォーマンスを積極的に確保し、ユーザーに一貫してポジティブな体験を提供することができます。