Diagnósticos do sistema e análise de uso

O Libre WebUI oferece aos administradores duas visualizações ao vivo da instância: uma página Sistema, com diagnósticos do host e do ambiente de execução, e uma página Uso, com análises de utilização de modelos e provedores. Ambas são exclusivas para administradores no backend e na interface. A leitura de qualquer uma das páginas permanece dentro da implantação; a telemetria externa opcional usa um caminho separado de Observabilidade, configurado pelo operador.

Acesse-as pelas entradas administrativas na barra lateral, pelos atalhos de administrador no menu de abas ou diretamente em /system e /usage. Usuários que não são administradores não podem abrir nenhuma das páginas, e as abas administrativas são fechadas quando uma conta conectada perde a função admin.

Diagnósticos do sistema

A página Sistema (/system) informa:

Host: nome do host, plataforma, versão do kernel, arquitetura, tempo de atividade, quantidade de CPUs lógicas, modelo da CPU, média de carga e se o processo parece estar em um contêiner. Não há percentual de uso da CPU; a carga da CPU é somente a média de carga.
Ambiente de execução: versão do aplicativo, versão do Node.js, ID do processo, tempo de atividade do processo e diretório de trabalho.
Memória: memória total, livre e usada do host, além dos valores de RSS e heap do processo.
Sistemas de arquivos: capacidade e uso do sistema de arquivos do ambiente de execução (/) e do diretório de dados (DATA_DIR).
Rede: nomes e endereços das interfaces, com contadores de bytes recebidos/transmitidos no Linux.
Docker: versão do mecanismo, sistema operacional do host, kernel, CPU e memória conforme informados pelo mecanismo, além das contagens de contêineres e de uma lista reduzida deles, quando o socket do Docker estiver disponível.

A página é atualizada a cada 30 segundos enquanto sua aba está em foco e tem um botão de atualização manual. O endpoint do backend é GET /api/system, protegido por autenticação, por uma função ativa de administrador e por um limite por usuário de 120 solicitações a cada 15 minutos. As respostas nunca são armazenadas em cache (Cache-Control: no-store), e cada solicitação coleta valores novos.

Dependência do socket do Docker

A seção do Docker resolve seu endpoint da mesma forma que o ambiente de execução do Work e o terminal interativo: WORK_DOCKER_SOCKET, quando definido (sempre um caminho de socket Unix local); caso contrário, DOCKER_HOST — uma URL unix:// ou um endpoint tcp:// em HTTP simples, como um proxy filtrado da API do Docker —; caso contrário, /var/run/docker.sock. Endpoints ssh:// e npipe://, assim como tcp:// com verificação TLS habilitada, deliberadamente não são consultados. As solicitações são estritamente operações GET de leitura do mecanismo (versão, informações e lista de contêineres), com tempo limite de 4 segundos e tamanho de resposta limitado; a lista de contêineres é limitada a 100 entradas.

Sem um socket utilizável, o restante da página continua funcionando: o painel do Docker informa por que ele está indisponível — socket não montado, montado mas sem permissão de leitura, daemon inacessível ou endpoint remoto — em vez de fazer a solicitação inteira falhar.

O que a página revela e para quem

A lista de contêineres é reduzida de propósito: ID curto, nome, imagem, estado e horário de criação. Variáveis de ambiente, rótulos, montagens, comandos dos contêineres e cargas de inspeção nunca são incluídos, e nenhuma credencial aparece na resposta.

Mesmo assim, a página mostra detalhes reais da infraestrutura — nome do host, diretório de trabalho, endereços IP internos e nomes e imagens de todos os contêineres no host Docker, não somente os do Libre WebUI. Isso é coerente com o modelo de confiança: em uma implantação com Docker, todo administrador do Libre WebUI já é, na prática, um administrador do host (consulte Docker). Conceda a função admin de acordo com essa responsabilidade.

Análise de uso

A página Uso (/usage) apresenta gráficos do trabalho de modelos e provedores atribuído a usuários. A medição ocorre em cada limite de execução compatível e, no momento, abrange:

chamadas de chat locais do Ollama, inclusive as chamadas do Chat nativo e do Work com Ollama;
chamadas de chat da CLI de agentes instalada;
chat fornecido por plugins, com e sem streaming;
embeddings de plugins, geração de imagens, conversão de fala em texto, conversão de texto em fala, som e vídeo; e
chamadas do Work fornecidas por plugins.

Operações em segundo plano sem um usuário proprietário deliberadamente não são atribuídas a uma conta sintética e, portanto, não são medidas. Uma chamada ainda é registrada quando falha ou é cancelada.

Cada evento registra:

ID do provedor/plugin e uma captura de seu nome de exibição (ollama e agent-cli:* usam o mesmo registro dos provedores de plugins)
recurso (chat, embedding, image, stt, tts, audio, video)
modelo
status: success, error ou cancelled (um fluxo interrompido conta como cancelado)
contagens de tokens, somente quando o provedor devolveu metadados de uso
contadores de unidades adequados ao recurso (caracteres para TTS, imagens, entradas de embedding, tarefas de vídeo e bytes de áudio)
duração de ponta a ponta e um carimbo de data e hora
ID do usuário solicitante

Nada mais é armazenado. Prompts, respostas, endpoints de provedores, credenciais e corpos de erro dos provedores nunca são gravados na tabela de uso — uma chamada com falha é registrada somente como status = 'error'. Os eventos ficam no banco de dados selecionado do aplicativo (SQLite no modo individual, PostgreSQL no modo de equipe) e são mantidos por 400 dias; linhas mais antigas são removidas de forma oportunista durante a gravação, no máximo uma vez por dia. A medição funciona por melhor esforço e nunca pode fazer uma solicitação a um modelo ou provedor falhar.

A página oferece intervalos de 7, 30 e 90 dias por meio de um único endpoint exclusivo para administradores, GET /api/plugins/usage?days=<1..365> (padrão 30). Ela mostra o total de chamadas, os tokens informados, a taxa de sucesso e a latência média, um gráfico diário que alterna entre chamadas e tokens, uma tabela por modelo, a participação no tráfego por plugin e a distribuição de recursos. Os totais de tokens incluem somente chamadas nas quais o provedor informou metadados de uso.

Não há opção para desabilitar a medição. Como os dados são agregados entre contas, sua inspeção é restrita aos administradores.

A página Uso informa chamadas, unidades, tokens, latência e resultados. Adicione a Governança de custos quando esses eventos precisarem de tarifas com vigência definida, detalhamento de gastos, orçamentos, alertas ou exportação contábil. Eventos sem uma tarifa correspondente ou sem uso informado pelo provedor permanecem visivelmente sem preço, em vez de serem tratados como gratuitos.

Atribuição do OpenRouter

Desde a versão 0.18.0, as solicitações ao OpenRouter identificam o aplicativo por meio dos cabeçalhos de atribuição do OpenRouter (HTTP-Referer: https://librewebui.org, um título do aplicativo e indicações de categoria). Esses cabeçalhos são enviados somente quando a solicitação vai para o próprio https://openrouter.ai — nunca para uma rota personalizada ou auto-hospedada — e não acrescentam nada ao que é armazenado localmente.