通过监控让您的 Open WebUI 保持健康 🩺

监控您的 Open WebUI 实例对于确保其可靠运行、性能良好以及快速识别和解决任何问题至关重要。本指南概述了三个级别的监控，从基本的可用性检查到深入的模型响应测试。

为何要监控？

• 确保正常运行时间： 主动检测服务中断和故障。
• 性能洞察： 跟踪响应时间并识别潜在瓶颈。
• 早期问题检测： 在问题对用户产生重大影响之前发现它们。
• 安心无忧： 确信您的 Open WebUI 实例运行顺利。

🚦 监控级别

我们将介绍三个监控级别，从基本到更全面

1. 基本健康检查： 验证 Open WebUI 服务是否正在运行并响应。
2. 模型连接检查： 确认 Open WebUI 可以连接到您配置的模型并列出它们。
3. 模型响应测试（深度健康检查）： 确保模型能够实际处理请求并生成响应。

级别 1：基本健康检查端点 ✅

最简单的监控级别是检查 /health 端点。此端点是公开可访问的（无需认证），当 Open WebUI 服务正常运行时，它会返回 200 OK 状态码。

如何测试

您可以使用 curl 或任何 HTTP 客户端检查此端点

   # Basic health check - no authentication needed
   curl https://your-open-webui-instance/health

预期输出： 成功的健康检查将返回 200 OK HTTP 状态码。对于基本健康检查，响应主体的内容通常不重要。

使用 Uptime Kuma 进行基本健康检查 🐻

Uptime Kuma 是一个非常棒的开源、易于使用的自托管正常运行时间监控工具。强烈推荐用于监控 Open WebUI。

在 Uptime Kuma 中设置的步骤

1. 添加新监控项： 在您的 Uptime Kuma 控制面板中，点击“添加新监控项”。
2. 配置监控项设置
   • 监控类型： 选择“HTTP(s)”。
   • 名称： 给您的监控项一个描述性的名称，例如，“Open WebUI 健康检查”。
   • URL： 输入健康检查端点 URL：http://your-open-webui-instance:8080/health （将 your-open-webui-instance:8080 替换为您的实际 Open WebUI 地址和端口）。
   • 监控间隔： 设置检查频率（例如，每分钟检查一次的 60 seconds）。
   • 重试次数： 设置在判定服务宕机前的重试次数（例如，3 次重试）。

此检查验证什么

• Web 服务器可用性： 确保 Web 服务器（例如 Nginx、Uvicorn）正在响应请求。
• 应用程序运行状态： 确认 Open WebUI 应用程序本身正在运行并已初始化。
• 基本数据库连接性： 通常包括一个基本检查，以确保应用程序可以连接到数据库。

级别 2：Open WebUI 模型连接性 🔗

要超越基本可用性检查，您可以监控 /api/models 端点。此端点需要认证，它验证 Open WebUI 是否能成功与您配置的模型提供商（例如 Ollama、OpenAI）通信并检索可用模型列表。

为何监控模型连接性？

• 模型提供商问题： 检测您的模型提供商服务的问题（例如 API 中断、认证失败）。
• 配置错误： 识别 Open WebUI 中模型提供商设置的错误配置。
• 确保模型可用： 确认您期望可用的模型实际上对 Open WebUI 可访问。

API 端点详情

有关 /api/models 端点及其响应结构的完整详情，请参阅Open WebUI API 文档。

如何使用 curl 测试（已认证）

您需要一个 API 密钥来访问此端点。请参阅下面的“API 密钥设置”部分了解生成 API 密钥的说明。

   # Authenticated model connectivity check
   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 数组（其中包含模型列表）的计数是否大于 0。换句话说，它验证是否至少返回了一个模型。
   • 预期值： true （如果列出了模型，则查询应返回 true）。

3. 添加认证头

   • 在 Uptime Kuma 监控配置的“Headers”部分，点击“Add Header”。
   • 头名称： Authorization
   • 头值： Bearer YOUR_API_KEY （将 YOUR_API_KEY 替换为您生成的 API 密钥）。

4. 设置监控间隔： 推荐间隔：300 seconds（5 分钟）或更长，因为模型列表通常不会非常频繁地更改。

备选 JSON 查询（高级）

您可以使用更具体的 JSONata 查询来检查特定模型或提供商。这里有一些示例

• 检查至少一个 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

您可以使用样本 API 响应在 jsonata.org 上测试和优化您的 JSONata 查询，以确保它们按预期工作。

级别 3：模型响应测试（深度健康检查）🤖

为了进行最全面的监控，您可以测试模型是否实际能够处理请求并生成响应。这涉及向 /api/chat/completions 端点发送一个简单的聊天完成请求。

为何测试模型响应？

• 端到端验证： 确认整个模型流水线正常工作，从 API 请求到模型响应。
• 模型加载问题： 检测特定模型加载或响应失败的问题。
• 后端处理错误： 捕获可能阻止模型生成完成的后端逻辑错误。

如何使用 curl 测试（已认证的 POST 请求）

此测试需要 API 密钥，并向聊天完成端点发送带有简单消息的 POST 请求。

# Test model response - authenticated POST request
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": "Respond with the word HEALTHY"}],
    "model": "llama3.1",  # Replace with a model you expect to be available
    "temperature": 0      # Set temperature to 0 for consistent responses
  }'

（将 YOUR_API_KEY、your-open-webui-instance 和 llama3.1 替换为您的实际值。）

预期输出： 成功的请求将返回 200 OK 状态码和包含聊天完成内容的 JSON 响应。您可以验证响应是否包含词语“HEALTHY”（或基于您的提示预期的类似响应）。

在 Uptime Kuma 中设置级别 3 监控将涉及配置带有 POST 请求、JSON 主体、认证头以及可能用于验证响应内容的 JSON 查询的 HTTP(s) 监控。这是一个更高级的设置，可以根据您的具体需求进行定制。

通过实施这些监控级别，您可以主动确保 Open WebUI 实例的健康、可靠性和性能，为用户提供始终如一的积极体验。