Systeemdiagnose en gebruiksanalyse

Libre WebUI biedt beheerders twee live weergaven van de instantie: een pagina Systeem met diagnose van host en runtime en een pagina Gebruik met analyse van model- en providergebruik. Beide zijn in backend en interface alleen voor beheerders. Het lezen van beide pagina's blijft binnen de implementatie; optionele externe telemetrie is een afzonderlijk, door de operator ingesteld pad voor Observeerbaarheid.

Open ze via de beheerdersvermeldingen in de zijbalk, de beheerderssnelkoppelingen in het tabbladmenu of rechtstreeks via /system en /usage. Niet-beheerders kunnen geen van beide pagina's openen en beheerderstabbladen worden gesloten als een aangemeld account de rol admin verliest.

Systeemdiagnose

De pagina Systeem (/system) meldt:

Host: hostnaam, platform, kernelrelease, architectuur, uptime, aantal logische CPU's, CPU-model, gemiddelde belasting en of het proces in een container lijkt te draaien. Er is geen percentage CPU-gebruik; CPU-belasting is alleen de gemiddelde belasting.
Runtime: toepassingsversie, Node.js-versie, proces-ID, procesuptime en werkmap.
Geheugen: totaal, vrij en gebruikt hostgeheugen plus RSS- en heapwaarden van het proces.
Bestandssystemen: capaciteit en gebruik van het runtimebestandssysteem (/) en de gegevensmap (DATA_DIR).
Netwerk: interfacenamen en -adressen, met tellers voor ontvangen/verzonden bytes op Linux.
Docker: engineversie, hostbesturingssysteem, kernel, CPU en geheugen zoals de engine die meldt, plus containeraantallen en een verkleinde containerlijst wanneer de Docker-socket beschikbaar is.

De pagina wordt elke 30 seconden vernieuwd zolang het tabblad actief is en heeft een knop voor handmatig vernieuwen. Het backendeindpunt is GET /api/system, beveiligd door verificatie, een actieve beheerdersrol en een limiet per gebruiker van 120 verzoeken per 15 minuten. Antwoorden worden nooit gecachet (Cache-Control: no-store) en elk verzoek verzamelt actuele waarden.

Afhankelijkheid van de Docker-socket

Het Docker-gedeelte bepaalt zijn eindpunt op dezelfde manier als de Work-runtime en interactieve terminal: WORK_DOCKER_SOCKET wanneer ingesteld (altijd een lokaal Unix-socketpad), anders DOCKER_HOST — een unix://-URL of een HTTP-eindpunt zonder TLS via tcp://, zoals een gefilterde Docker API-proxy — en anders /var/run/docker.sock. Eindpunten met ssh:// en npipe://, en tcp:// met ingeschakelde TLS-verificatie, worden bewust niet bevraagd. De verzoeken zijn strikt alleen-lezen GET-aanroepen van de engine (versie, informatie, containerlijst), met een time-out van 4 seconden en begrensde antwoordgrootte; de containerlijst is beperkt tot 100 vermeldingen.

Zonder bruikbare socket werkt de rest van de pagina nog steeds: het Docker-paneel meldt waarom Docker niet beschikbaar is — socket niet gekoppeld, gekoppeld maar onleesbaar, daemon onbereikbaar of extern eindpunt — in plaats van het hele verzoek te laten mislukken.

Wat de pagina toont en aan wie

De containerlijst is bewust beperkt tot korte ID, naam, image, status en aanmaaktijd. Omgevingsvariabelen, labels, mounts, containeropdrachten en inspectiepayloads worden nooit opgenomen en nergens in het antwoord staan referenties.

De pagina toont wel echte infrastructuurdetails: hostnaam, werkmap, interne IP-adressen en namen en images van elke container op de Docker-host, niet alleen die van Libre WebUI. Dat past bij het vertrouwensmodel: in een Docker-implementatie is elke Libre WebUI-beheerder feitelijk al hostbeheerder (zie Docker). Ken de rol admin dienovereenkomstig toe.

Gebruiksanalyse

De pagina Gebruik brengt aan gebruikers toegeschreven model- en providerwerk in kaart. Meting vindt plaats bij elke ondersteunde uitvoeringsgrens en omvat momenteel:

lokale Ollama-chataanroepen, waaronder eigen Chat- en door Ollama ondersteunde Work-aanroepen;
chataanroepen via geïnstalleerde agent-CLI's;
chats via plugins, met en zonder streaming;
embeddings, beeldgeneratie, spraak-naar-tekst, tekst-naar-spraak, geluid en video via plugins; en
Work-aanroepen via plugins.

Achtergrondbewerkingen zonder eigenaar worden bewust niet aan een synthetisch account toegewezen en daarom niet gemeten. Een aanroep wordt ook vastgelegd wanneer die mislukt of wordt geannuleerd.

Elke gebeurtenis bewaart:

provider-/plugin-ID en een momentopname van de weergavenaam (ollama en agent-cli:* gebruiken hetzelfde logboek als pluginproviders)
mogelijkheid (chat, embedding, image, stt, tts, audio, video)
model
status: success, error of cancelled (een afgebroken stream telt als geannuleerd)
tokenaantallen, alleen als de provider gebruiksmetagegevens heeft geretourneerd
tellers die bij de mogelijkheid passen (tekens voor TTS, afbeeldingen, embeddinginvoer, taken voor video, bytes voor audio)
totale duur en tijdstempel
ID van de aanvragende gebruiker

Verder wordt niets opgeslagen. Prompts, antwoorden, providereindpunten, referenties en providerfoutbody's worden nooit naar de gebruikstabel geschreven — een mislukte aanroep wordt alleen als status = 'error' vastgelegd. De gebeurtenissen staan in de geselecteerde toepassingsdatabase (SQLite in solomodus, PostgreSQL in teammodus) en worden 400 dagen bewaard; oudere rijen worden opportunistisch bij schrijven verwijderd, maximaal eenmaal per dag. Meting is bewust op basis van beste inspanning en kan nooit een model- of providerverzoek laten mislukken.

De pagina biedt bereiken van 7, 30 en 90 dagen via één eindpunt alleen voor beheerders, GET /api/plugins/usage?days=<1..365> (standaard 30). De pagina toont totale aanroepen, gemelde tokens, succespercentage en gemiddelde latentie; een daggrafiek die tussen aanroepen en tokens kan wisselen; een tabel per model; verkeersaandelen per plugin en de verdeling van mogelijkheden. Tokentotalen omvatten alleen aanroepen waarvoor de provider gebruiksmetagegevens meldde.

Er is geen schakelaar om meting uit te schakelen. Omdat de gegevens over accounts worden samengevoegd, mogen alleen beheerders ze bekijken.

De pagina Gebruik meldt aanroepen, eenheden, tokens, latentie en uitkomsten. Voeg Kostenbeheer toe wanneer deze gebeurtenissen tarieven met ingangsdatum, uitsplitsingen van uitgaven, budgetten, waarschuwingen of boekhoudkundige export vereisen. Gebeurtenissen zonder passend tarief of door de provider gemeld gebruik blijven zichtbaar ongeprijsd in plaats van als gratis te worden beschouwd.

OpenRouter-toeschrijving

Sinds 0.18.0 identificeren verzoeken aan OpenRouter de toepassing via de app-toeschrijvingsheaders van OpenRouter (HTTP-Referer: https://librewebui.org, een toepassingstitel en categorieaanwijzingen). Deze headers worden alleen verzonden wanneer het verzoek naar https://openrouter.ai zelf gaat — nooit naar een aangepaste of zelfgehoste route — en voegen niets toe aan wat lokaal wordt opgeslagen.