Следите за состоянием вашего Open WebUI с мониторингом 🩺

Мониторинг вашей установки Open WebUI крайне важен для обеспечения её стабильной работы, высокой производительности, а также для быстрого обнаружения и устранения проблем. В этом руководстве описаны три уровня мониторинга — от базовой проверки доступности до глубинного тестирования ответов моделей.

Зачем нужен мониторинг?

• Обеспечение времени работы: Проактивное обнаружение сбоев и перебоев в обслуживании.
• Анализ производительности: Отслеживание времени отклика и выявление потенциальных узких мест.
• Раннее обнаружение проблем: Обнаруживайте проблемы до того, как они значительно повлияют на пользователей.
• Спокойствие: Уверенность в том, что ваш Open WebUI работает без сбоев.

🚦 Уровни мониторинга

Мы рассмотрим три уровня мониторинга, переходя от базового к более углублённому:

1. Базовая проверка работоспособности: Проверяет, запущена ли служба Open WebUI и отвечает ли она.
2. Проверка подключений моделей: Удостоверяется, что Open WebUI может подключиться и отобразить ваши настроенные модели.
3. Тестирование ответов моделей (глубинная проверка): Убедитесь, что модели могут обрабатывать запросы и генерировать ответы.

Уровень 1: Конечная точка базовой проверки ✅

Самый простой уровень мониторинга — это проверка конечной точки /health. Эта точка общедоступна (аутентификация не требуется) и возвращает статус-код 200 OK, когда служба Open WebUI работает корректно.

Как провести тест:

Вы можете использовать curl или любой HTTP-клиент для проверки этой конечной точки:

   # Базовая проверка — аутентификация не требуется
   curl https://your-open-webui-instance/health

Ожидаемый результат: Успешная проверка здоровья вернет HTTP-статус-код 200 OK. Обычно содержимое тела ответа не имеет значения для базовой проверки.

Использование 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 (Замените your-open-webui-instance:8080 на фактический адрес и порт вашего Open WebUI).
   • Интервал мониторинга: Установите частоту проверок (например, 60 секунд для проверки каждую минуту).
   • Количество повторов: Установите количество повторов перед признанием прекращения работы сервиса (например, 3 повторения).

Что проверяет эта проверка:

• Доступность веб-сервера: Убедитесь, что веб-сервер (например, 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.)

Ожидаемый результат: Успешный запрос вернет HTTP-статус-код 200 OK и JSON-ответ, содержащий список моделей.

Настройка аутентификации для API-ключа 🔑

Перед тем как подключиться к конечной точке /api/models, необходимо включить API-ключи в Open WebUI и создать один:

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 проверяет, содержит ли массив data в ответе API (который включает список моделей) количество элементов больше 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 на jsonata.org с использованием примерного ответа API, чтобы убедиться, что они работают должным образом.

Уровень 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": "Ответьте словом ЗДОРОВО"}],
    "model": "llama3.1",  # Замените модель на ожидаемую
    "temperature": 0      # Установите температуру 0 для получения консистентных ответов
  }

(Замените YOUR_API_KEY, your-open-webui-instance и llama3.1 на ваши актуальные значения.)

Ожидаемый результат: Успешный запрос вернёт статус 200 OK и JSON ответ с диалоговым завершением. Вы можете убедиться, что ответ включает слово "ЗДОРОВО" (или аналогичный ожидаемый ответ, основанный на вашем запросе).

Настройка мониторинга уровня 3 в Uptime Kuma может включать конфигурацию HTTP(s) монитора с запросом POST, JSON телом, заголовками аутентификации и, возможно, JSON запросом для проверки содержимого ответа. Это более сложная настройка, которая может быть адаптирована под ваши специфические нужды.

Реализуя эти уровни мониторинга, вы сможете активно обеспечивать здоровье, надёжность и производительность вашей Open WebUI инстанции, предоставляя пользователям стабильный положительный опыт.