html 📊 Monitorando seu webui aberto | Nullcore
Pule para o conteúdo principal

Mantenha seu webui aberto saudável com o monitoramento 🩺

O monitoramento da sua instância Nullcore é crucial para garantir que ela funcione de maneira confiável, tenha um bom desempenho e permite identificar e resolver rapidamente quaisquer problemas. Este guia descreve três níveis de monitoramento, desde verificações básicas de disponibilidade até testes de resposta a modelos detalhados.

Por que monitorar?

  • Garanta o tempo de atividade:Detectar proativamente interrupções e interrupções do serviço.
  • Insights de desempenho:Rastreie os tempos de resposta e identifique possíveis gargalos.
  • Detecção de edição antecipada:Assistir aos problemas antes que eles afetem significativamente os usuários.
  • Paz de espírito:Ganhe confiança de que sua instância aberta da Webui está funcionando sem problemas.

🚦 Níveis de monitoramento

Abordaremos três níveis de monitoramento, progredindo de básico para mais abrangente:

  1. Verificação básica de saúde:Verifica se o serviço Nullcore estiver em execução e respondendo.
  2. Verificação de conectividade do modelo:Confirma que o Nullcore pode se conectar e listar seus modelos configurados.
  3. Teste de resposta ao modelo (verificação de saúde profunda):Garante que os modelos possam realmente processar solicitações e gerar respostas.

Nível 1: Ponto de extremidade básico de verificação de saúde ✅

O nível mais simples de monitoramento é verificar o/healthendpoint. Este endpoint é acessível ao público (sem autenticação necessária) e retorna um200 OKCódigo de status quando o serviço Nullcore estiver em execução corretamente.

Como testar:

Você pode usarcurlou qualquer cliente HTTP para verificar este terminal:

# Verificação básica de saúde - nenhuma autenticação necessária
Curl https: // your -pen-webui-instance/Health

Saída esperada:Uma verificação de saúde bem -sucedida retornará um200 OKCódigo de status HTTP. O conteúdo do corpo de resposta geralmente não é importante para uma verificação básica de saúde.

Usando o Uptime Kuma para verificações básicas de saúde 🐻

Uptime Kumaé uma ferramenta de monitoramento de tempo de atividade auto-hospedada fantástica, de código aberto e fácil de usar. É altamente recomendado para monitorar o Webui aberto.

Etapas a serem configuradas no tempo de atividade Kuma:

  1. Adicione um novo monitor:No seu painel Kuma de tempo de atividade, clique em "Adicionar novo monitor".
  2. Defina as configurações do monitor:
    • Tipo de monitor:Selecione "HTTP (s)".
    • Nome:Dê ao seu monitor um nome descritivo, por exemplo, "Abra a verificação de saúde da webui".
    • URL:Digite o URL do ponto de extremidade de verificação de saúde:http://your-open-webui-instance:8080/health(Substituiryour-open-webui-instance:8080com seu endereço e porta de webui aberto reais).
    • Intervalo de monitoramento:Defina a frequência de cheques (por exemplo,,60 secondspara cada minuto).
    • Representação de repetição:Defina o número de tentativas antes de considerar o serviço para baixo (por exemplo,,3tentativas).

O que essa verificação verifica:

  • Disponibilidade do servidor da web:Garante que o servidor da Web (por exemplo, Nginx, Uvicorn) esteja respondendo às solicitações.
  • Aplicativo em execução:Confirma que o próprio aplicativo Nullcore está em execução e inicializado.
  • Conectividade básica do banco de dados:Normalmente inclui uma verificação básica para garantir que o aplicativo possa se conectar ao banco de dados.

Nível 2: Abrir conectividade do modelo webui 🔗

Para ir além da disponibilidade básica, você pode monitorar o/api/modelsendpoint. Este terminalrequer autenticaçãoe verifica se o Nullcore pode se comunicar com sucesso com seus provedores de modelos configurados (por exemplo, Ollama, Openai) e recuperar uma lista de modelos disponíveis.

Por que monitorar a conectividade do modelo?

  • Questões de provedores de modelos:Detecte problemas com seus serviços de provedor de modelos (por exemplo, interrupções na API, falhas de autenticação).
  • Erros de configuração:Identifique as configurações incorretas nas configurações do seu provedor de modelos no Webui aberto.
  • Garanta a disponibilidade do modelo:Confirme que os modelos que você espera estar disponível estão realmente acessíveis para abrir o WebUI.

Detalhes do terminal da API:

Veja oDocumentação da API Webui abertaPara detalhes completos sobre o/api/modelsendpoint e sua estrutura de resposta.

Como testar comcurl(Autenticado):

Você precisará de uma chave da API para acessar este terminal. Consulte a seção "Configuração de autenticação" abaixo para obter instruções sobre como gerar uma chave de API.

# Verificação de conectividade do modelo autenticado
Curl -H "Autorização: Bearer Your_Api_Key" https: // your-open-webui-instance/api/modelos

(SubstituirYOUR_API_KEYcom sua chave de API real eyour-open-webui-instancecom seu endereço de webui aberto.)

Saída esperada:Um pedido bem -sucedido retornará um200 OKCódigo de status e uma resposta JSON contendo uma lista de modelos.

Configuração de autenticação para a chave da API 🔑

Antes de poder monitorar o/api/modelsendpoint, você precisa ativar as teclas da API em Webui aberto e gerar uma:

  1. Ativar teclas de API (obrigatório admin):

    • Faça login para abrir o Webui como administrador.
    • Vá paraConfigurações do administrador(geralmente no menu superior direito)>Em geral
    • Encontre a configuração "Ativar chave da API" eligue
    • CliqueSalvar alterações
  2. Gere uma chave da API (configurações do usuário):

    • Vá para o seuConfigurações do usuário(geralmente clicando no seu ícone de perfil no canto superior direito).
    • Navegue até oContaseção.
    • CliqueGerar nova chave de API
    • Dê à chave da API um nome descritivo (por exemplo, "Monitorando a chave da API").
    • Copie a chave da API geradae guarde -o com segurança. Você precisará disso para sua configuração de monitoramento.

    (Opcional, mas recomendado):Para práticas recomendadas de segurança, considere criar umConta de usuário não administradorEspecificamente para monitorar e gerar uma chave de API para esse usuário. Isso limita o impacto potencial se a chave da API de monitoramento estiver comprometida.

    Se você não vir a opção de geração de chaves da API em suas configurações, entre em contato com o Administrador Nullcore para garantir que as teclas da API estejam ativadas.

Usando o uptime kuma para monitoramento de conectividade do modelo 🐻

  1. Crie um novo monitor no tempo de atividade Kuma:

    • Tipo de monitor: "HTTP (S) - JSON Query".
    • Nome: "Abra a verificação de conectividade do modelo Webui".
    • URL:http://your-open-webui-instance:8080/api/models(Substitua pelo seu URL).
    • Método: "Get".
    • Código de status esperado:200
  2. Configure a consulta JSON (verifique a lista de modelos):

    • Consulta JSON: $count(data[*])>0
      • Explicação:Esta consulta jsonata verifica se odataA matriz na resposta da API (que contém a lista de modelos) tem uma contagem superior a 0. Em outras palavras, verifica que pelo menos um modelo é retornado.
    • Valor esperado: true(A consulta deve retornartrueSe os modelos estiverem listados).
  3. Adicionar cabeçalhos de autenticação:

    • Na seção "cabeçalhos" da configuração do monitor Kuma de tempo de atividade, clique em "Adicionar cabeçalho".
    • Nome do cabeçalho: Authorization
    • Valor do cabeçalho: Bearer YOUR_API_KEY(SubstituirYOUR_API_KEYcom a chave da API que você gerou).
  4. Definir intervalo de monitoramento:Intervalo recomendado:300 seconds(5 minutos) ou mais, pois as listas de modelos normalmente não mudam com muita frequência.

Consultas JSON alternativas (Avançado):

Você pode usar consultas JsonATA mais específicas para verificar modelos ou provedores específicos. Aqui estão alguns exemplos:

  • Verifique se há pelo menos um modelo Ollama: $count(data[owned_by='ollama'])>0
  • Verifique se existe um modelo específico (por exemplo, 'GPT-4O'): $exists(data[id='gpt-4o'])
  • Verifique se vários modelos específicos existem (por exemplo, 'GPT-4O' e 'GPT-4O-Mini'): $count(data[id in ['gpt-4o', 'gpt-4o-mini']]) = 2

Você pode testar e refinar suas consultas jsonata emjsonata.orgUsando uma resposta da API de amostra para garantir que eles funcionem conforme o esperado.

Nível 3: Teste de resposta ao modelo (verificação de saúde profunda) 🤖

Para o monitoramento mais abrangente, você pode testar se os modelos são realmente capazes de processar solicitações e gerar respostas. Isso envolve o envio de uma solicitação de conclusão de bate -papo simples para o/api/chat/completionsendpoint.

Por que testar as respostas do modelo?

  • Verificação de ponta a ponta:Confirma que todo o pipeline do modelo está funcionando, desde a solicitação da API até o modelo de resposta.
  • Problemas de carregamento de modelo:Detecta problemas com modelos específicos que não conseguem carregar ou responder.
  • Erros de processamento de back -end:Capta erros na lógica de back -end que podem impedir que os modelos gerem conclusões.

Como testar comcurl(Solicitação de postagem autenticada):

Este teste requer uma chave da API e envia uma solicitação de postagem com uma mensagem simples para o terminal de conclusão do bate -papo.

# Resposta do modelo de teste - solicitação de postagem autenticada
Curl -x Post https: // your -pen-webui-instance/api/chat/conclusões \
-H "Autorização: Portador Your_Api_Key" \
-H "Tipo de Conteúdo: Aplicativo/JSON" \
-d '{
"Mensagens": [{"função": "usuário", "conteúdo": "responda com a palavra saudável"}],
"Modelo": "LLAMA3.1", # Substitua por um modelo que você espera estar disponível
"Temperatura": 0 # Defina a temperatura para 0 para respostas consistentes
} '

(SubstituirYOUR_API_KEY, Assim,your-open-webui-instance, ellama3.1com seus valores reais.)

Saída esperada:Um pedido bem -sucedido retornará um200 OKCódigo de status e uma resposta JSON contendo uma conclusão de bate -papo. Você pode verificar se a resposta inclui a palavra "saudável" (ou uma resposta esperada semelhante com base no seu prompt).

A configuração do monitoramento de nível 3 no tempo de atividade Kuma envolveria a configuração de um monitor HTTP (s) com uma solicitação de postagem, órgão JSON, cabeçalhos de autenticação e consulta potencialmente JSON para validar o conteúdo da resposta. Esta é uma configuração mais avançada e pode ser personalizada com base em suas necessidades específicas.

Ao implementar esses níveis de monitoramento, você pode garantir proativamente a saúde, a confiabilidade e o desempenho de sua instância aberta da Webui, fornecendo uma experiência consistentemente positiva para os usuários.