Hop til hovedindhold

Systemdiagnostik og brugsanalyse

Libre WebUI giver administratorer to aktuelle visninger af instansen: en side for System med værts- og kørselsdiagnostik og en side for Usage med analyse af model- og udbyderbrug. Begge er kun for administratorer i backend og grænsefladen. Læsning af siderne bliver inden for installationen. Valgfri ekstern telemetri er en separat, operatørkonfigureret vej til observerbarhed.

Åbn dem fra administratorpunkterne i sidepanelet, fanemenuens administratorgenveje eller direkte på /system og /usage. Ikke-administratorer kan ikke åbne siderne, og administratorfanerne lukkes, hvis en konto, der er logget ind, mister rollen admin.

Systemdiagnostik

Systemsiden (/system) viser:

  • Vært: værtsnavn, platform, kerneversion, arkitektur, oppetid, antal logiske CPU'er, CPU-model, belastningsgennemsnit og om processen ser ud til at være containeriseret. Der vises ingen procentvis CPU-udnyttelse; CPU-belastning er kun belastningsgennemsnittet.
  • Kørselstid: programversion, Node.js-version, proces-ID, processens oppetid og arbejdsmappe.
  • Hukommelse: værtens samlede, ledige og brugte hukommelse samt processens RSS- og heapværdier.
  • Filsystemer: kapacitet og brug for kørselsfilsystemet (/) og datamappen (DATA_DIR).
  • Netværk: grænsefladenavne og adresser med tællere for modtagne/sendte bytes på Linux.
  • Docker: motorversion, værts-OS, kerne, CPU og hukommelse, som motoren rapporterer, samt containerantal og en reduceret containerliste, når Docker-socketen er tilgængelig.

Siden opdateres hvert 30. sekund, mens fanen har fokus, og har en manuel opdateringsknap. Backend-slutpunktet er GET /api/system, beskyttet af godkendelse, en aktiv administratorrolle og en hastighedsgrænse pr. bruger på 120 anmodninger pr. 15 minutter. Svar caches aldrig (Cache-Control: no-store), og hver anmodning indsamler friske værdier.

Afhængighed af Docker-socket

Docker-afsnittet finder sit slutpunkt på samme måde som Work-kørselstiden og den interaktive terminal: WORK_DOCKER_SOCKET, når den er angivet (altid en lokal Unix-socketsti), ellers DOCKER_HOST — en unix://-URL eller et almindeligt HTTP-tcp://-slutpunkt, for eksempel en filtreret Docker API-proxy — og ellers /var/run/docker.sock. Slutpunkter med ssh:// og npipe:// samt tcp:// med TLS-verificering aktiveret forespørges bevidst ikke. Anmodningerne er strengt skrivebeskyttede GET-kald til Docker-motoren (version, info, containerliste), har fire sekunders timeout og en begrænset svarstørrelse. Containerlisten er begrænset til 100 poster.

Uden en brugbar socket virker resten af siden stadig. Docker-panelet rapporterer, hvorfor det ikke er tilgængeligt — socketen er ikke monteret, er monteret men ulæselig, dæmonen kan ikke nås, eller slutpunktet er eksternt — i stedet for at hele anmodningen mislykkes.

Hvad siden viser og til hvem

Containerlisten er bevidst reduceret: kort ID, navn, image, tilstand og oprettelsestid. Miljøvariabler, labels, mounts, containerkommandoer og inspect-data medtages aldrig, og der vises ingen legitimationsoplysninger nogen steder i svaret.

Siden viser stadig reelle infrastrukturdetaljer — værtsnavn, arbejdsmappe, interne IP-adresser samt navne og images for alle containere på Docker-værten, ikke kun Libre WebUI's. Det stemmer overens med tillidsmodellen: I en Docker-installation er hver Libre WebUI-administrator allerede reelt værtsadministrator (se Docker). Tildel rollen admin derefter.

Brugsanalyse

Siden Usage (/usage) viser diagrammer over model- og udbyderarbejde, der kan henføres til brugere. Måling sker ved hver understøttet udførelsesgrænse og dækker i øjeblikket:

  • lokale Ollama-chatkald, herunder indbyggede Chat- og Ollama-baserede Work-kald;
  • chatkald gennem installerede agent-CLI'er;
  • pluginbaseret chat, både streamet og ikke-streamet;
  • plugin-embeddings, billedgenerering, tale-til-tekst, tekst-til-tale, lyd og video; og
  • pluginbaserede Work-kald.

Baggrundshandlinger uden en ejende bruger tildeles bevidst ikke en syntetisk konto og måles derfor ikke. Et kald registreres stadig, når det mislykkes eller annulleres.

Hver hændelse registrerer:

  • udbyder-/plugin-ID og et øjebliksbillede af visningsnavnet (ollama og agent-cli:* bruger samme journal som pluginudbydere)
  • funktion (chat, embedding, image, stt, tts, audio, video)
  • model
  • status: success, error eller cancelled (en afbrudt stream tæller som annulleret)
  • tokenantal, kun når udbyderen returnerede brugsmetadata
  • enhedstællere, der passer til funktionen (tegn til TTS, billeder, embeddinginput, jobs til video og bytes til lyd)
  • samlet varighed og et tidsstempel
  • ID'et for brugeren, der sendte anmodningen

Intet andet gemmes. Prompter, svar, udbyderslutpunkter, legitimationsoplysninger og udbydernes fejlbodyer skrives aldrig til brugstabellen — et mislykket kald registreres kun som status = 'error'. Hændelserne ligger i den valgte programdatabase (SQLite i solo-tilstand, PostgreSQL i teamtilstand) og opbevares i 400 dage. Ældre rækker ryddes opportunistisk ved skrivning, højst én gang om dagen. Målingen udføres bevidst uden leveringsgaranti og kan aldrig få en model- eller udbyderanmodning til at mislykkes.

Siden tilbyder intervaller på 7, 30 og 90 dage gennem ét slutpunkt kun for administratorer, GET /api/plugins/usage?days=<1..365> (standard 30). Den viser samlet antal kald, rapporterede tokens, succesrate og gennemsnitlig latenstid, et dagligt diagram, der kan skifte mellem kald og tokens, en tabel pr. model, trafikandele pr. plugin og funktionsfordelingen. Tokensummer omfatter kun kald, hvor udbyderen rapporterede brugsmetadata.

Der findes ingen kontakt til at deaktivere målingen. Da data samles på tværs af konti, er gennemgang begrænset til administratorer.

Siden Usage rapporterer kald, enheder, tokens, latenstid og resultater. Tilføj omkostningsstyring, når hændelserne kræver tidsbestemte takster, omkostningsfordelinger, budgetter, advarsler eller regnskabseksport. Hændelser uden en matchende takst eller udbyderrapporteret brug vises som ikke-prissat i stedet for at blive behandlet som gratis.

OpenRouter-attribution

Siden 0.18.0 identificerer anmodninger til OpenRouter programmet gennem OpenRouters headere til appattribution (HTTP-Referer: https://librewebui.org, en programtitel og kategorihints). Disse headere sendes kun, når anmodningen går til https://openrouter.ai selv — aldrig til en tilpasset eller selvhostet rute — og tilføjer intet til det, der gemmes lokalt.

Relateret dokumentation