Diagnostica di sistema e analisi dell'utilizzo

Libre WebUI offre agli amministratori due viste in tempo reale dell'istanza: una pagina Sistema con la diagnostica dell'host e del runtime e una pagina Utilizzo con l'analisi dell'utilizzo dei modelli e dei provider. Entrambe sono riservate agli amministratori nel backend e nell'interfaccia. La lettura delle due pagine resta all'interno del deployment; la telemetria esterna facoltativa segue invece un percorso di osservabilità separato e configurato dall'operatore.

Puoi raggiungerle dalle voci amministrative nella barra laterale, dalle scorciatoie per amministratori nel menu delle schede oppure direttamente agli indirizzi /system e /usage. Gli utenti non amministratori non possono aprire le due pagine e le schede di amministrazione vengono chiuse se un account connesso perde il ruolo admin.

Diagnostica di sistema

La pagina Sistema (/system) mostra:

Host: nome host, piattaforma, versione del kernel, architettura, tempo di attività, numero di CPU logiche, modello della CPU, carico medio e rilevamento della probabile esecuzione in container. Non è disponibile una percentuale di utilizzo della CPU; il carico della CPU corrisponde soltanto al carico medio.
Runtime: versione dell'applicazione, versione di Node.js, ID del processo, tempo di attività del processo e directory di lavoro.
Memoria: memoria totale, libera e usata dell'host, insieme ai valori RSS e heap del processo.
File system: capacità e utilizzo del file system di runtime (/) e della directory dei dati (DATA_DIR).
Rete: nomi e indirizzi delle interfacce, con contatori dei byte ricevuti/trasmessi su Linux.
Docker: versione del motore, sistema operativo dell'host, kernel, CPU e memoria comunicati dal motore, oltre ai conteggi dei container e a un elenco ridotto, quando il socket Docker è disponibile.

La pagina viene aggiornata ogni 30 secondi mentre la relativa scheda è attiva e dispone di un pulsante per l'aggiornamento manuale. L'endpoint del backend è GET /api/system, protetto da autenticazione, ruolo di amministratore attivo e limite per utente di 120 richieste ogni 15 minuti. Le risposte non vengono mai memorizzate nella cache (Cache-Control: no-store) e ogni richiesta raccoglie valori aggiornati.

Dipendenza dal socket Docker

La sezione Docker risolve il proprio endpoint nello stesso modo del runtime Work e del terminale interattivo: WORK_DOCKER_SOCKET, se impostato (sempre un percorso di socket Unix locale); in alternativa DOCKER_HOST, ovvero un URL unix:// o un endpoint tcp:// HTTP semplice, ad esempio un proxy filtrato dell'API Docker; altrimenti /var/run/docker.sock. Gli endpoint ssh:// e npipe:// e gli endpoint tcp:// con verifica TLS abilitata non vengono interrogati intenzionalmente. Le richieste sono esclusivamente operazioni GET di sola lettura sul motore (versione, informazioni ed elenco dei container), con timeout di 4 secondi e dimensione della risposta limitata; l'elenco dei container è limitato a 100 voci.

Senza un socket utilizzabile, il resto della pagina continua a funzionare: il pannello Docker indica il motivo dell'indisponibilità, ovvero socket non montato, montato ma illeggibile, daemon irraggiungibile o endpoint remoto, anziché far fallire l'intera richiesta.

Informazioni mostrate dalla pagina e relativi destinatari

L'elenco dei container è ridotto intenzionalmente: ID breve, nome, immagine, stato e ora di creazione. Variabili di ambiente, etichette, mount, comandi dei container e payload di ispezione non vengono mai inclusi e nella risposta non appare alcuna credenziale.

La pagina mostra comunque dettagli reali dell'infrastruttura: nome host, directory di lavoro, indirizzi IP interni e nomi e immagini di tutti i container sull'host Docker, non soltanto quelli di Libre WebUI. Ciò è coerente con il modello di fiducia: in un deployment Docker, ogni amministratore di Libre WebUI è già di fatto un amministratore dell'host (vedi Docker). Assegna il ruolo admin di conseguenza.

Analisi dell'utilizzo

La pagina Utilizzo presenta grafici del lavoro di modelli e provider attribuito agli utenti. La misurazione avviene a ogni confine di esecuzione supportato e al momento comprende:

chiamate alle chat Ollama locali, incluse la chat nativa e le chiamate Work basate su Ollama;
chiamate alle chat degli agenti CLI installati;
chat basate su plugin, con e senza streaming;
embedding, generazione di immagini, trascrizione vocale, sintesi vocale, audio e video basati su plugin; e
chiamate Work basate su plugin.

Le operazioni in background prive di un utente proprietario non vengono assegnate intenzionalmente a un account sintetico e pertanto non vengono misurate. Una chiamata viene comunque registrata se non riesce o viene annullata.

Ogni evento registra:

ID del provider/plugin e uno snapshot del nome visualizzato (ollama e agent-cli:* usano lo stesso registro dei provider plugin)
funzionalità (chat, embedding, image, stt, tts, audio, video)
modello
stato: success, error o cancelled (uno stream interrotto viene conteggiato come annullato)
conteggi dei token, soltanto quando il provider ha restituito metadati sull'utilizzo
contatori di unità appropriati alla funzionalità (caratteri per TTS, immagini, input degli embedding, processi per i video, byte per l'audio)
durata complessiva e timestamp
ID dell'utente che ha effettuato la richiesta

Non viene archiviato altro. Prompt, risposte, endpoint dei provider, credenziali e corpi degli errori dei provider non vengono mai scritti nella tabella di utilizzo: una chiamata non riuscita viene registrata soltanto come status = 'error'. Gli eventi risiedono nel database dell'applicazione selezionato (SQLite in modalità individuale, PostgreSQL in modalità team) e vengono conservati per 400 giorni; le righe più vecchie vengono eliminate in modo opportunistico in fase di scrittura, al massimo una volta al giorno. La misurazione è intenzionalmente basata sul massimo impegno e non può mai causare l'errore di una richiesta a un modello o provider.

La pagina offre intervalli di 7, 30 e 90 giorni tramite un unico endpoint riservato agli amministratori, GET /api/plugins/usage?days=<1..365> (valore predefinito 30). Mostra chiamate totali, token comunicati, percentuale di successo e latenza media, un grafico giornaliero commutabile tra chiamate e token, una tabella per modello, le quote di traffico per plugin e la distribuzione delle funzionalità. I totali dei token comprendono soltanto le chiamate per cui il provider ha comunicato metadati sull'utilizzo.

Non esiste un interruttore per disabilitare la misurazione. Poiché i dati vengono aggregati tra gli account, la loro consultazione è riservata agli amministratori.

La pagina Utilizzo riporta chiamate, unità, token, latenza e risultati. Aggiungi la governance dei costi quando per tali eventi servono tariffe con validità temporale, ripartizioni della spesa, budget, avvisi o esportazione contabile. Gli eventi senza una tariffa corrispondente o senza utilizzo comunicato dal provider restano visibilmente senza prezzo anziché essere considerati gratuiti.

Attribuzione OpenRouter

Dalla versione 0.18.0, le richieste a OpenRouter identificano l'applicazione tramite le intestazioni di attribuzione delle app di OpenRouter (HTTP-Referer: https://librewebui.org, un titolo dell'applicazione e indicazioni sulla categoria). Queste intestazioni vengono inviate soltanto quando la richiesta è diretta a https://openrouter.ai, mai a una route personalizzata o self-hosted, e non aggiungono nulla ai dati archiviati localmente.