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

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

为什么要监控？

• 确保正常运行时间： 主动检测中断和服务中断。
• 性能洞察： 跟踪响应时间并识别潜在瓶颈。
• 早期问题检测： 在问题显著影响用户之前发现它们。
• 内心平静： 获得对 Open WebUI 实例正常运行的信心。

🚦 监控级别

我们将涵盖三个监控级别，从基本到更全面：

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 仪表板中，点击"添加新监控器"。
2. 配置监控器设置：
   • 监控器类型： 选择"HTTP(s)"。
   • 名称： 为您的监控器起一个描述性名称，例如"Open WebUI 健康检查"。
   • URL： 输入健康检查端点 URL：http://your-open-webui-instance:8080/health（将 your-open-webui-instance:8080 替换为您实际的 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 端点详情：

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

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

3. 添加身份验证标头：

   • 在 Uptime Kuma 监控器配置的"标头"部分，点击"添加标头"。
   • 标头名称： Authorization
   • 标头值： Bearer YOUR_API_KEY（将 YOUR_API_KEY 替换为您生成的 API 密钥）。

4. 设置监控间隔： 推荐间隔：300 秒（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

您可以在 jsonata.org 使用示例 API 响应测试和完善您的 JSONata 查询，以确保它们按预期工作。

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

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

为什么要测试模型响应？

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

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

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

# 测试模型响应 - 已认证的 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": "Respond with the word 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 实例的健康、可靠性和性能，为用户提供始终如一的积极体验。