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, y compris Chat natif et Work via Ollama ;
les appels de chat des CLI d’agents installés et les appels du moteur Strands ;
les chats via plugins, en continu ou non ;
les embeddings, la génération d’images, la transcription, la synthèse vocale, le son et la vidéo via plugins ; et
les appels Work via 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 :

identifiant du fournisseur/plugin et instantané de son nom affiché (ollama et agent-cli:* utilisent le même registre que les fournisseurs de plugins)
fonctionnalité (chat, embedding, image, stt, tts, audio, video)
modèle
statut : success, error ou cancelled (un flux interrompu compte comme annulé)
compteurs de jetons, seulement lorsque le fournisseur renvoie des métadonnées d’utilisation
compteurs d’unités adaptés à la fonctionnalité (caractères pour TTS, images, entrées d’embedding, tâches vidéo, octets audio)
durée de bout en bout et horodatage
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, la latence moyenne et la part des appels ayant signalé une consommation de jetons. La consultation de la page se fait en lecture seule et s’appuie sur le registre d’utilisation existant du déploiement.

Utilisation des agents

La section Agents, près du haut de la page (Appels aux agents CLI et au moteur Strands), présente séparément Claude Code, Codex, OpenCode, Pi et Strands. Elle indique les appels, les jetons signalés, les appels échoués ou annulés, la durée moyenne et jusqu’à 20 modèles les plus utilisés de chaque agent. Les totaux des agents couvrent tous les appels correspondants de la période, indépendamment des limites d’affichage des grandes tables de fournisseurs et de modèles. Ce sont des sous-ensembles des totaux de la page, pas des événements facturables supplémentaires.

Un agent sans enregistrement affiche Aucun appel enregistré sur cette période. Cela n’indique pas si sa CLI est installée ou connectée. Les appels sans métadonnées de jetons affichent Jetons non signalés ; les compteurs manquants ne sont pas estimés. La page s’actualise toutes les 20 secondes lorsqu’elle est visible et propose aussi une actualisation manuelle.

L’utilisation CLI enregistre une invocation et les compteurs de jetons signalés par cette CLI. Les instantanés cumulatifs remplacent les précédents, et les rapports répétés par étape sont dédupliqués. Les compteurs de cache et de raisonnement sont combinés selon le protocole de chaque CLI, sans compter deux fois des sous-ensembles. Les invocations annulées et réponses partielles se terminant en échec conservent leur résultat réel.

Les appels Strands sont attribués à l’agent Strands. Le moteur n’a pas de fournisseur de modèles propre : chaque appel de modèle qu’il effectue passe par les fournisseurs Ollama ou de plugins de Libre WebUI. Les appels extérieurs à LWUI ne sont pas importés. Les anciens enregistrements sans compteurs de jetons restent non mesurés.

Le point d’accès expose cette ventilation bornée dans agents, avec les cinq noms pris en charge même si leurs compteurs sont nuls. La lecture ne découvre pas de modèles CLI, ne lance pas d’agents et ne contacte pas de fournisseurs. Les anciens serveurs dépourvus de ce champ peuvent afficher les entrées d’agents enregistrées dans leur ventilation par fournisseur ; les agents absents n’y sont pas présentés comme ayant une utilisation nulle confirmée.

Explorer les modèles et les fournisseurs

Les couleurs des modèles relient le graphique quotidien, le calendrier d’activité annuel, le tableau des modèles et les barres des fournisseurs. Les noms de modèles, les valeurs et les indicateurs de sélection accompagnent ces couleurs. Le calendrier d’activité couvre toujours les 365 derniers jours, indépendamment de la plage sélectionnée ; la couleur de chaque jour identifie son modèle le plus utilisé.

Le graphique quotidien bascule entre Appels et Jetons. Survolez un modèle dans sa légende ou amenez-y le focus clavier pour suivre sa courbe. Sélectionnez le modèle pour le garder en évidence, sélectionnez-le de nouveau pour le relâcher, ou choisissez Afficher tous les modèles pour réinitialiser. Le tableau des modèles propose lui aussi une action de mise en évidence. La mise en évidence change l’emphase tout en préservant les totaux quotidiens, les valeurs du tableau et les totaux par fournisseur.

Déplacez le pointeur sur le graphique ou utilisez Explorer l’utilisation quotidienne pour inspecter le total d’une journée et sa répartition par modèle. Le curseur quotidien se pilote au clavier : les touches fléchées passent d’un jour à l’autre, et Origine/Fin atteignent le premier et le dernier jour. Les tranches quotidiennes et leurs libellés utilisent UTC.

Par défaut, le graphique affiche les 12 noms de modèles les plus appelés sur la période sélectionnée, y compris en vue des jetons. Chaque modèle reste inspectable individuellement : donnez le focus ou sélectionnez un modèle dans le tableau ou dans le détail d’un fournisseur pour charger sa courbe quotidienne exacte, même s’il ne fait pas partie de ces 12. Un message de chargement nomme le modèle demandé pendant la récupération de son historique.

La courbe d’un modèle supplémentaire est séparée d’Autres modèles, et le groupe restant exclut ses appels, ses jetons signalés et ses échecs. Le graphique contient au plus 13 courbes de modèles nommés en plus du groupe restant, et leurs valeurs quotidiennes se réconcilient toujours avec les mêmes totaux. Choisissez Afficher tous les modèles pour revenir à la vue par défaut.

Les courbes quotidiennes regroupent les appels portant le même nom de modèle enregistré chez différents fournisseurs. Le tableau des modèles conserve des entrées fournisseur/modèle distinctes : un même modèle peut donc apparaître sous plusieurs fournisseurs. Les modèles nommés conservent des couleurs individuelles dans le tableau et dans les barres des fournisseurs, y compris ceux qui sont absents du graphique par défaut.

Le détail des fournisseurs indique la part des requêtes de chaque fournisseur, une barre découpée par modèle, les jetons signalés, les appels échoués ou annulés et le temps de réponse moyen. La répartition des capacités reste disponible sous les détails par modèle et par fournisseur.

Les totaux de jetons comprennent uniquement les appels pour lesquels le fournisseur a renvoyé des métadonnées d’utilisation. Le pourcentage de couverture rend visible un signalement partiel ; les jetons manquants ne sont jamais estimés à partir des requêtes ni d’un autre modèle. Une période sans jetons signalés affiche une explication dans la vue Jetons, et son historique de requêtes reste disponible dans Appels.

Le point de terminaison inclut les points quotidiens par modèle dans modelSeries. Un paramètre de requête model facultatif demande un nom de modèle enregistré exact en plus des 12 principaux, par exemple GET /api/plugins/usage?days=30&model=<encoded-model-name>. Il s’agit du même point de terminaison réservé aux administrateurs et en lecture seule : il interroge le registre d’utilisation local et n’appelle jamais un fournisseur de modèles pour récupérer un historique.

Un paramètre to facultatif fixe la borne de fin de la requête à un horodatage Unix en millisecondes. Il exige model et n’accepte qu’un entier sûr non négatif, au plus égal à l’heure actuelle du serveur. Le navigateur envoie le range.to de la vue d’ensemble lors du chargement d’un modèle individuel, ce qui préserve ses limites de jour et d’année UTC et exclut les appels postérieurs à cet horodatage. Sans to, le point de terminaison utilise l’heure actuelle.

Le chargement d’un modèle laisse en place les cartes, le tableau, les totaux par fournisseur et les couleurs de la vue d’ensemble. Sa courbe quotidienne n’est ajoutée que si les bornes temporelles et les totaux quotidiens de la réponse correspondent à cette vue d’ensemble. Cette borne temporelle ne fige pas la base de données : si des reprises d’historique ou des suppressions modifient ces totaux, le navigateur actualise la vue d’ensemble avant d’afficher la courbe du modèle.

Si un serveur plus ancien omet modelSeries, le graphique affiche la série agrégée Tous les modèles avec une explication indiquant que la répartition par modèle est indisponible. Le tableau des modèles reste disponible ; le navigateur ne déduit pas l’historique quotidien par modèle à partir des totaux de la période ni du calendrier annuel.

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.