Diagnostika systému a analýza používání

Libre WebUI dává správcům dva živé pohledy na instanci: stránku System s diagnostikou hostitele a běhu a stránku Usage s analýzou používání modelů a poskytovatelů. Obě jsou v backendu i rozhraní dostupné pouze správcům. Jejich čtení zůstává uvnitř instalace; volitelná externí telemetrie používá samostatnou, operátorem nastavenou cestu observability.

Otevřete je z položek správce v postranním panelu, zkratek v nabídce karet nebo přímo na /system a /usage. Běžní uživatelé stránky otevřít nemohou a pokud přihlášený účet ztratí roli admin, karty správce se zavřou.

Diagnostika systému

Stránka System (/system) uvádí:

Hostitel: název, platformu, verzi jádra, architekturu, dobu běhu, počet logických CPU, model CPU, průměrnou zátěž a zda proces vypadá jako spuštěný v kontejneru. Procento využití CPU se nezobrazuje; zátěž je pouze průměrná zátěž.
Běhové prostředí: verzi aplikace a Node.js, ID procesu, dobu běhu procesu a pracovní adresář.
Paměť: celkovou, volnou a použitou paměť hostitele a hodnoty RSS a haldy procesu.
Souborové systémy: kapacitu a využití souborového systému běhu (/) a datového adresáře (DATA_DIR).
Síť: názvy a adresy rozhraní; v Linuxu i počitadla přijatých a odeslaných bajtů.
Docker: verzi enginu, operační systém hostitele, jádro, CPU a paměť vykázanou enginem, počty kontejnerů a omezený seznam kontejnerů, pokud je dostupný socket Docker.

Stránka se při zaměření karty obnovuje každých 30 sekund a má tlačítko ručního obnovení. Koncový bod backendu GET /api/system chrání ověřování, aktivní role správce a limit 120 požadavků na uživatele za 15 minut. Odpovědi se nikdy neukládají do mezipaměti (Cache-Control: no-store) a každý požadavek sbírá aktuální hodnoty.

Závislost na socketu Docker

Sekce Docker volí koncový bod stejně jako běh Work a interaktivní terminál: WORK_DOCKER_SOCKET, pokud je nastaven (vždy místní cesta k socketu Unix), jinak DOCKER_HOST — URL unix:// nebo prostý HTTP koncový bod tcp://, například filtrovaná proxy Docker API — a jinak /var/run/docker.sock. Koncové body ssh:// a npipe:// ani tcp:// se zapnutým ověřováním TLS se záměrně nedotazují. Požadavky jsou výhradně jen pro čtení pomocí GET enginu (version, info, seznam kontejnerů), mají čtyřsekundový časový limit a omezenou velikost odpovědi. Seznam má nejvýše 100 položek.

Bez použitelného socketu zbytek stránky stále funguje. Panel Docker oznámí důvod nedostupnosti — socket není připojen, je nečitelný, démon není dosažitelný nebo jde o vzdálený koncový bod — namísto selhání celého požadavku.

Co stránka odhaluje a komu

Seznam kontejnerů je záměrně omezený: krátké ID, název, image, stav a čas vytvoření. Proměnné prostředí, štítky, připojení, příkazy kontejnerů ani data inspect se nikdy nezahrnují a v odpovědi nejsou žádné přihlašovací údaje.

Stránka přesto ukazuje skutečné podrobnosti infrastruktury — název hostitele, pracovní adresář, interní IP adresy a názvy a images všech kontejnerů na hostiteli Docker, nejen Libre WebUI. Odpovídá to modelu důvěry: v instalaci Docker je každý správce Libre WebUI prakticky správcem hostitele (viz Docker). Roli admin přidělujte podle toho.

Analýza používání

Stránka Usage (/usage) zobrazuje práci modelů a poskytovatelů přiřazenou uživatelům. Měření probíhá na každé podporované hranici spuštění a nyní zahrnuje:

místní volání chatu Ollama, včetně nativního Chat a Work s Ollama;
volání chatu nainstalovaných agentů CLI;
chat přes pluginy se streamováním i bez něj;
embeddingy, generování obrázků, řeč na text, text na řeč, zvuk a video přes pluginy; a
volání Work přes pluginy.

Operace na pozadí bez vlastnícího uživatele se záměrně nepřiřazují syntetickému účtu a neměří se. Volání se zaznamená i při selhání nebo zrušení.

Každá událost zaznamená:

ID poskytovatele či pluginu a snímek jeho zobrazovaného názvu (ollama a agent-cli:* používají stejnou účetní knihu jako pluginy)
funkci (chat, embedding, image, stt, tts, audio, video)
model
stav: success, error nebo cancelled (přerušený proud se počítá jako zrušený)
počty tokenů pouze tehdy, pokud poskytovatel vrátil metadata používání
jednotky odpovídající funkci (znaky pro TTS, obrázky, vstupy embeddingů, úlohy videa, bajty zvuku)
celkovou dobu a časové razítko
ID žádajícího uživatele

Nic dalšího se neukládá. Prompty, odpovědi, koncové body poskytovatelů, přihlašovací údaje a těla jejich chyb se nikdy nezapisují do tabulky používání — neúspěšné volání se zaznamená jen jako status = 'error'. Události jsou ve vybrané aplikační databázi (SQLite v sólovém režimu, PostgreSQL v týmovém) a uchovávají se 400 dní. Starší řádky se při zápisu příležitostně mažou, nejvýše jednou denně. Měření je záměrně bez záruky doručení a nikdy nemůže způsobit selhání požadavku na model či poskytovatele.

Stránka nabízí rozsahy 7, 30 a 90 dní přes jediný koncový bod pouze pro správce, GET /api/plugins/usage?days=<1..365> (výchozí 30). Ukazuje celkový počet volání, vykázané tokeny, úspěšnost a průměrnou latenci, denní graf přepínatelný mezi voláními a tokeny, tabulku modelů, podíly provozu pluginů a mix funkcí. Součty tokenů zahrnují jen volání, u nichž poskytovatel vrátil metadata používání.

Měření nelze vypnout. Protože jsou data agregovaná mezi účty, smí je prohlížet jen správci.

Stránka Usage vykazuje volání, jednotky, tokeny, latenci a výsledky. Přidejte správu nákladů, pokud události potřebují časově platné tarify, rozpis výdajů, rozpočty, upozornění nebo účetní export. Události bez odpovídajícího tarifu nebo vykázaného používání zůstanou viditelně bez ceny, nepovažují se za bezplatné.

Atribuce OpenRouter

Od verze 0.18.0 požadavky na OpenRouter identifikují aplikaci pomocí hlaviček atribuce OpenRouter (HTTP-Referer: https://librewebui.org, název aplikace a náznaky kategorií). Odesílají se pouze na samotný https://openrouter.ai, nikdy na vlastní či lokální trasu, a nepřidávají nic k místně ukládaným datům.