Diagnostics système et analyse de l’utilisation

Libre WebUI offre aux administrateurs deux vues en direct de l’instance : une page Système consacrée aux diagnostics de l’hôte et de l’environnement d’exécution, et une page Utilisation dédiée à l’analyse de l’utilisation des modèles et des fournisseurs. Toutes deux sont réservées aux administrateurs dans le backend et l’interface. La consultation de ces pages reste à l’intérieur du déploiement ; la télémétrie externe facultative suit un parcours d’observabilité distinct et configuré par l’opérateur.

Accédez-y depuis les entrées d’administration de la barre latérale, les raccourcis d’administration du menu d’onglets, ou directement via /system et /usage. Les utilisateurs qui ne sont pas administrateurs ne peuvent ouvrir aucune de ces pages, et les onglets d’administration se ferment si un compte connecté perd le rôle admin.

Diagnostics système

La page Système (/system) présente :

Hôte : nom d’hôte, plateforme, version du noyau, architecture, durée de fonctionnement, nombre de CPU logiques, modèle du CPU, charge moyenne et détection de l’exécution probable dans un conteneur. Aucun pourcentage d’utilisation du CPU n’est affiché ; seule la charge moyenne représente sa charge.
Environnement d’exécution : version de l’application, version de Node.js, identifiant du processus, durée de fonctionnement du processus et répertoire de travail.
Mémoire : mémoire totale, libre et utilisée de l’hôte, ainsi que les valeurs RSS et de tas du processus.
Systèmes de fichiers : capacité et utilisation du système de fichiers de l’environnement d’exécution (/) et du répertoire de données (DATA_DIR).
Réseau : noms et adresses des interfaces, avec compteurs d’octets reçus et transmis sous Linux.
Docker : version du moteur, système d’exploitation de l’hôte, noyau, CPU et mémoire tels que rapportés par le moteur, nombre de conteneurs et liste réduite des conteneurs lorsque le socket Docker est disponible.

La page s’actualise toutes les 30 secondes lorsque son onglet a le focus et comporte un bouton d’actualisation manuelle. Le point de terminaison du backend est GET /api/system. Il est protégé par l’authentification, un rôle d’administrateur actif et une limite par utilisateur de 120 requêtes par tranche de 15 minutes. Les réponses ne sont jamais mises en cache (Cache-Control: no-store) et chaque requête recueille de nouvelles valeurs.

Dépendance au socket Docker

La section Docker résout son point de terminaison comme l’environnement d’exécution Work et le terminal interactif : WORK_DOCKER_SOCKET lorsqu’il est défini (toujours un chemin de socket Unix local), sinon DOCKER_HOST — une URL unix:// ou un point de terminaison tcp:// en HTTP simple, par exemple un proxy filtré de l’API Docker — ou, à défaut, /var/run/docker.sock. Les points de terminaison ssh:// et npipe://, ainsi que les points tcp:// dont la vérification TLS est activée, ne sont délibérément pas interrogés. Les requêtes sont strictement des appels GET en lecture seule au moteur (version, informations, liste des conteneurs), avec un délai d’expiration de 4 secondes et une taille de réponse limitée ; la liste des conteneurs est limitée à 100 entrées.

Sans socket utilisable, le reste de la page continue de fonctionner : le volet Docker indique pourquoi il est indisponible — socket non monté, monté mais illisible, démon inaccessible ou point de terminaison distant — au lieu de faire échouer toute la requête.

Informations révélées par la page et destinataires

La liste des conteneurs est volontairement réduite : identifiant court, nom, image, état et date de création. Les variables d’environnement, étiquettes, montages, commandes des conteneurs et charges utiles d’inspection ne sont jamais inclus, et aucun identifiant secret n’apparaît dans la réponse.

La page affiche néanmoins de véritables détails d’infrastructure : nom d’hôte, répertoire de travail, adresses IP internes, ainsi que noms et images de tous les conteneurs de l’hôte Docker, pas seulement ceux de Libre WebUI. Cela correspond au modèle de confiance : dans un déploiement Docker, chaque administrateur Libre WebUI est déjà, dans les faits, administrateur de l’hôte (voir Docker). Attribuez le rôle admin en conséquence.

Analyse de l’utilisation

La page Utilisation représente le travail des modèles et des fournisseurs attribué aux utilisateurs. La mesure intervient à chaque frontière d’exécution prise en charge et couvre actuellement :

les appels de chat Ollama locaux, notamment les appels natifs du chat et ceux de Work reposant sur Ollama ;
les appels de chat des agents CLI installés ;
les chats fournis par des plugins, avec ou sans diffusion en continu ;
les embeddings, la génération d’images, la transcription de la parole, la synthèse vocale, le son et la vidéo fournis par des plugins ; et
les appels Work fournis par des plugins.

Les opérations en arrière-plan sans utilisateur propriétaire ne sont délibérément pas attribuées à un compte synthétique et ne sont donc pas mesurées. Un appel reste enregistré lorsqu’il échoue ou est annulé.

Chaque événement enregistre :

l’identifiant du fournisseur ou du plugin et un instantané de son nom affiché (ollama et agent-cli:* utilisent le même registre que les fournisseurs par plugin) ;
la capacité (chat, embedding, image, stt, tts, audio, video) ;
le modèle ;
l’état : success, error ou cancelled (un flux interrompu est compté comme annulé) ;
le nombre de jetons, uniquement lorsque le fournisseur renvoie les métadonnées d’utilisation ;
les compteurs d’unités adaptés à la capacité (caractères pour TTS, images, entrées d’embedding, tâches vidéo, octets audio) ;
la durée de bout en bout et un horodatage ;
l’identifiant de l’utilisateur à l’origine de la requête.

Rien d’autre n’est stocké. Les invites, réponses, points de terminaison des fournisseurs, identifiants et corps d’erreurs des fournisseurs ne sont jamais écrits dans la table d’utilisation : un appel en échec est uniquement enregistré sous status = 'error'. Les événements résident dans la base de données d’application sélectionnée (SQLite en mode individuel, PostgreSQL en mode équipe) et sont conservés pendant 400 jours ; les lignes plus anciennes sont élaguées de façon opportuniste lors d’une écriture, au plus une fois par jour. La mesure est conçue pour fonctionner au mieux et ne peut jamais faire échouer une requête adressée à un modèle ou un fournisseur.

La page propose des plages de 7, 30 et 90 jours via un seul point de terminaison réservé aux administrateurs, GET /api/plugins/usage?days=<1..365> (valeur par défaut : 30). Elle présente le nombre total d’appels, les jetons signalés, le taux de réussite et la latence moyenne, un graphique quotidien basculant entre appels et jetons, un tableau par modèle, la part de trafic de chaque plugin et la répartition des capacités. Les totaux de jetons comprennent uniquement les appels pour lesquels le fournisseur a renvoyé des métadonnées d’utilisation.

Il n’existe aucun bouton pour désactiver la mesure. Comme les données sont agrégées entre les comptes, seuls les administrateurs peuvent les consulter.

La page Utilisation présente les appels, unités, jetons, latences et résultats. Ajoutez la gouvernance des coûts lorsque ces événements exigent des tarifs avec dates d’effet, une ventilation des dépenses, des budgets, des alertes ou une exportation comptable. Les événements sans tarif correspondant ou sans utilisation signalée par le fournisseur restent visiblement non tarifés au lieu d’être considérés comme gratuits.

Attribution OpenRouter

Depuis 0.18.0, les requêtes adressées à OpenRouter identifient l’application au moyen des en-têtes d’attribution d’application d’OpenRouter (HTTP-Referer: https://librewebui.org, un titre d’application et des indications de catégorie). Ces en-têtes sont envoyés uniquement lorsque la requête cible https://openrouter.ai lui-même, jamais une route personnalisée ou auto-hébergée, et n’ajoutent rien aux données stockées localement.