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, inklusive native Chat og Ollama-baseret Work;
  • chatkald til installerede agent-CLI'er og kald til Strands-motoren;
  • pluginbaseret chat med og uden streaming;
  • pluginbaserede embeddings, billeder, talegenkendelse, talegenerering, lyd og video;
  • samt 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 snapshot af navnet (ollama og agent-cli:* bruger samme ledger som pluginudbydere)
  • funktion (chat, embedding, image, stt, tts, audio, video)
  • model
  • status: success, error eller cancelled (en afbrudt stream tæller som annulleret)
  • tokens, kun når udbyderen returnerer forbrugsmetadata
  • relevante enheder (TTS-tegn, billeder, embeddinginput, videojobs og lydbytes)
  • samlet varighed og tidsstempel
  • den anmodende brugers id

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, gennemsnitlig latenstid og andelen af kald, der rapporterede tokenforbrug. At læse siden er en ren læseoperation, der bruger installationens eksisterende brugsjournal.

Agentforbrug​

Afsnittet Agenter øverst (Kald til CLI-agenter og Strands-motoren) viser Claude Code, Codex, OpenCode, Pi og Strands hver for sig. Her vises kald, tokens, fejl og annulleringer, gennemsnitsvarighed og op til 20 mest brugte modeller. Agenttotaler omfatter alle matchende kald i perioden uafhængigt af de større tabellers visningsgrænser. De er delmængder af sidens totaler, ikke ekstra fakturerbare hændelser.

En agent uden registreringer viser Ingen registrerede kald i denne periode. Det siger ikke, om dens CLI er installeret eller logget ind. Kald uden tokenmetadata viser Tokens ikke rapporteret; manglende tællere estimeres ikke. Siden opdateres hvert 20. sekund, mens den er synlig, og kan også opdateres manuelt.

CLI-forbrug gemmer én invocation og de tællere, CLI'et rapporterer. Kumulative snapshots erstatter tidligere snapshots, og gentagne trinrapporter deduplikeres. Cache- og ræsonnementstællere kombineres efter det enkelte CLI's protokol uden at tælle delmængder to gange. Annullerede kald og delvise svar, som slutter med fejl, beholder det faktiske udfald.

Strands-kald tilskrives agenten Strands. Motoren har ingen egen modeludbyder. Hvert modelkald, den foretager, går gennem Libre WebUI's Ollama- eller pluginudbydere. Kald uden for LWUI importeres ikke. Ældre poster uden tokentællere forbliver umålte.

Endpointet udstiller den begrænsede opdeling i agents med alle fem navne, også ved nul tællere. Læsning opdager ikke CLI-modeller, starter ikke agenter og kontakter ikke udbydere. Ældre servere uden feltet kan vise registrerede agenter fra udbyderopdelingen; manglende poster fremstilles ikke som bekræftet nulforbrug.

Udforsk modeller og udbydere​

Modelfarverne binder det daglige diagram, den årlige aktivitetskalender, modeltabellen og udbyderstolpene sammen. Modelnavne, værdier og markeringer følger altid med farverne. Aktivitetskalenderen dækker altid de seneste 365 dage uafhængigt af det valgte interval, og hver dags farve angiver dagens mest brugte model.

Det daglige diagram skifter mellem Kald og Tokens. Hold markøren over en model i signaturforklaringen, eller flyt tastaturfokus dertil for at følge modellens linje. Vælg modellen for at bevare fremhævningen, vælg den igen for at slippe den, eller vælg Vis alle modeller for at nulstille. Modeltabellen har også en fremhævningshandling. Fremhævning ændrer kun vægtningen og bevarer dagssummer, tabelværdier og udbydersummer.

Før markøren hen over diagrammet, eller brug Udforsk dagligt forbrug til at se en dags total og fordeling pr. model. Dagskyderen understøtter tastaturet: piletaster flytter mellem dage, og Home/End når den første og den sidste dag. Dagsintervallerne og deres etiketter bruger UTC.

Som standard viser diagrammet de tolv modelnavne med flest kald i det valgte interval, også når du ser på tokens. Hver model kan stadig undersøges enkeltvis: fokusér eller vælg en model i tabellen eller i udbyderdetaljerne for at indlæse dens præcise daglige linje, også når den ligger uden for de tolv. En indlæsningsbesked nævner den ønskede model, mens historikken hentes.

En tilføjet models linje adskilles fra Andre modeller, og den resterende gruppe udelader dens kald, rapporterede tokens og fejl. Diagrammet indeholder højst tretten navngivne modellinjer plus den resterende gruppe, og deres daglige værdier stemmer fortsat med de samme totaler. Vælg Vis alle modeller for at vende tilbage til standardvisningen.

Daglige linjer samler kald med det samme registrerede modelnavn på tværs af udbydere. Modeltabellen bevarer separate udbyder-/modelposter, så den samme model kan optræde under mere end én udbyder. Navngivne modeller beholder egne farver i tabellen og i udbyderstolpene, også modeller uden for standarddiagrammet.

Udbyderdetaljerne viser hver udbyders andel af anmodningerne, en stolpe opdelt pr. model, rapporterede tokens, mislykkede eller annullerede kald og gennemsnitlig svartid. Funktionsfordelingen findes fortsat under model- og udbyderopdelingerne.

Tokensummer omfatter kun kald, hvor udbyderen rapporterede brugsmetadata. Dækningsprocenten gør ufuldstændig rapportering synlig; manglende tokental estimeres aldrig ud fra antallet af anmodninger eller ud fra en anden model. En periode uden rapporterede tokens viser en forklaring i Tokens-visningen, og dens anmodningshistorik er fortsat tilgængelig under Kald.

Slutpunktet indeholder daglige modelpunkter i modelSeries. En valgfri forespørgselsparameter model anmoder om ét præcist registreret modelnavn ved siden af de tolv mest brugte, for eksempel GET /api/plugins/usage?days=30&model=<encoded-model-name>. Det er det samme slutpunkt kun for administratorer og kun til læsning: det spørger den lokale brugsjournal og kalder aldrig en modeludbyder for at hente historik.

En valgfri parameter to låser anmodningens slutgrænse til et Unix-tidsstempel i millisekunder. Den kræver model og accepterer kun et ikke-negativt sikkert heltal, der ikke ligger senere end serverens aktuelle tid. Browseren sender oversigtens range.to, når en enkelt model indlæses, hvilket bevarer dens UTC-grænser for dag og år og udelader kald efter det tidsstempel. Uden to bruger slutpunktet det aktuelle tidspunkt.

At indlæse en model bevarer oversigtens kort, tabel, udbydersummer og farver. Dens daglige linje tilføjes kun, når svarets tidsgrænser og dagssummer stemmer med den oversigt. Tidsgrænsen fryser ikke databasen: hvis historiske efterfyldninger eller sletninger ændrer de summer, opdaterer browseren oversigten, før modellinjen vises.

Hvis en ældre server udelader modelSeries, viser diagrammet den samlede serie Alle modeller med en forklaring om, at modelopdelingen ikke er tilgængelig. Modeltabellen er fortsat tilgængelig; browseren udleder ikke daglig modelhistorik fra periodetotaler eller fra årskalenderen.

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​