Saltar al contenido principal

Diagnóstico del sistema y análisis de uso

Libre WebUI proporciona a los administradores dos vistas en directo de la instancia: una página de Sistema con diagnóstico del host y del entorno de ejecución, y una página de Uso con análisis de modelos y proveedores. Ambas están restringidas a administradores en el backend y la interfaz. Consultarlas permanece dentro del despliegue; la telemetría externa opcional es una ruta de observabilidad independiente y configurada por el operador.

Se accede desde las entradas administrativas de la barra lateral, los accesos directos del menú de pestañas o directamente en /system y /usage. Quienes no son administradores no pueden abrirlas, y las pestañas se cierran si una cuenta pierde el rol admin.

Diagnóstico del sistema​

La página Sistema (/system) muestra:

  • Host: nombre, plataforma, versión del kernel, arquitectura, tiempo activo, número de CPU lógicas, modelo de CPU, carga media y si el proceso parece estar en un contenedor. No hay porcentaje de uso de CPU; solo se muestra la carga media.
  • Entorno de ejecución: versión de la aplicación, versión de Node.js, ID y tiempo activo del proceso y directorio de trabajo.
  • Memoria: memoria total, libre y usada del host, además del RSS y el heap del proceso.
  • Sistemas de archivos: capacidad y uso del sistema de ejecución (/) y el directorio de datos (DATA_DIR).
  • Red: nombres y direcciones de interfaces, con contadores de bytes recibidos y transmitidos en Linux.
  • Docker: versión del motor, SO del host, kernel, CPU y memoria comunicados por el motor, además del número de contenedores y una lista reducida cuando el socket está disponible.

La página se actualiza cada 30 segundos mientras su pestaña tiene el foco y ofrece un botón manual. El endpoint es GET /api/system, protegido por autenticación, un rol de administrador activo y un límite por usuario de 120 solicitudes cada 15 minutos. Las respuestas nunca se almacenan (Cache-Control: no-store) y cada solicitud recoge valores nuevos.

Dependencia del socket de Docker​

La sección Docker resuelve su endpoint igual que el entorno de Work y la terminal: WORK_DOCKER_SOCKET cuando está definido (siempre una ruta de socket Unix local), en su defecto DOCKER_HOST —una URL unix:// o un endpoint tcp:// por HTTP sin cifrar, como un proxy filtrado de la API— y, por último, /var/run/docker.sock. No se consultan deliberadamente endpoints ssh:// o npipe://, ni tcp:// con verificación TLS. Las solicitudes son únicamente GET de lectura al motor (versión, información y lista), con un tiempo de 4 segundos y tamaño acotado; la lista se limita a 100 entradas.

Sin un socket utilizable, el resto de la página sigue funcionando: el panel explica si no está montado, no es legible, el daemon no responde o el endpoint es remoto, en lugar de hacer fallar toda la solicitud.

Qué revela la página y a quién​

La lista se reduce deliberadamente a ID corto, nombre, imagen, estado y fecha de creación. Nunca incluye variables de entorno, etiquetas, montajes, comandos ni cargas de inspección, y no aparecen credenciales en la respuesta.

La página sí muestra detalles reales de infraestructura: nombre del host, directorio de trabajo, IP internas y nombres e imágenes de todos los contenedores del host, no solo los de Libre WebUI. Es coherente con el modelo de confianza: en Docker, cada administrador de Libre WebUI es en la práctica administrador del host (consulta Docker). Concede admin en consecuencia.

Análisis de uso​

La página Uso representa trabajo de modelos y proveedores atribuido a usuarios. La medición se realiza en cada límite de ejecución admitido y actualmente abarca:

  • llamadas de chat Ollama locales, incluido Chat nativo y Work mediante Ollama;
  • llamadas de chat a CLI de agentes instaladas y llamadas del motor Strands;
  • chat mediante plugins, con o sin streaming;
  • embeddings, imágenes, transcripción, síntesis de voz, sonido y vídeo mediante plugins; y
  • llamadas Work mediante plugins.

Las operaciones en segundo plano sin un usuario propietario no se asignan a una cuenta sintética y no se miden. Una llamada se registra aunque falle o se cancele.

Cada evento registra:

  • identificador del proveedor/plugin e instantánea de su nombre (ollama y agent-cli:* usan el mismo registro que los proveedores de plugins)
  • capacidad (chat, embedding, image, stt, tts, audio, video)
  • modelo
  • estado: success, error o cancelled (un flujo abortado cuenta como cancelado)
  • tokens solo cuando el proveedor devolvió metadatos de uso
  • unidades correspondientes a cada capacidad (caracteres para TTS, imágenes, entradas de embeddings, trabajos de vídeo y bytes de audio)
  • duración completa y marca de tiempo
  • identificador del usuario solicitante

No se almacena nada más. Los prompts, las respuestas, los endpoints, las credenciales y los cuerpos de error del proveedor nunca se escriben en la tabla de uso: una llamada fallida solo se registra como status = 'error'. Los eventos viven en la base elegida (SQLite en modo individual, PostgreSQL en modo equipo) y se conservan durante 400 días; las filas anteriores se podan de forma oportunista al escribir, como máximo una vez al día. La medición es de mejor esfuerzo y nunca puede hacer fallar una solicitud.

La página ofrece intervalos de 7, 30 y 90 días mediante un endpoint administrativo, GET /api/plugins/usage?days=<1..365> (30 por defecto). Muestra llamadas totales, tokens comunicados, tasa de éxito, latencia media y la proporción de llamadas que comunicaron uso de tokens. Consultar la página es una operación de solo lectura sobre el registro de uso ya existente del despliegue.

Uso de agentes​

La sección Agentes, cerca de la parte superior (Llamadas a agentes CLI y al motor Strands), muestra Claude Code, Codex, OpenCode, Pi y Strands por separado. Incluye llamadas, tokens reportados, fallos o cancelaciones, duración media y hasta 20 modelos más usados por agente. Los totales cubren todas sus llamadas en el período, independientemente de los límites de las tablas generales de proveedores y modelos. Son subconjuntos de los totales de página, no eventos facturables adicionales.

Un agente sin registros indica No hay llamadas registradas en este período. No significa que su CLI esté instalada ni autenticada. Las llamadas sin metadatos de tokens indican Tokens no reportados; no se estiman contadores ausentes. La página se actualiza cada 20 segundos mientras está visible y permite actualizar manualmente.

El uso CLI registra una invocación y los contadores reportados por esa CLI. Las instantáneas acumuladas sustituyen las anteriores y se deduplican los informes repetidos por paso. Caché y razonamiento se combinan conforme al protocolo de cada CLI, sin contar subconjuntos dos veces. Las invocaciones canceladas y respuestas parciales que terminan en error conservan su resultado real.

Las llamadas de Strands se atribuyen al agente Strands. El motor no tiene un proveedor de modelos propio; cada llamada al modelo que hace pasa por los proveedores de Ollama o de plugins de Libre WebUI. No se importan llamadas externas a LWUI. Los registros antiguos sin contadores siguen sin medición de tokens.

El endpoint expone este desglose limitado en agents, incluidos los cinco nombres admitidos aunque sus contadores sean cero. Leerlo no descubre modelos CLI, inicia agentes ni contacta proveedores. Los servidores antiguos sin este campo pueden mostrar agentes registrados en el desglose por proveedor; la ausencia de una entrada no se presenta como uso cero confirmado.

Explorar modelos y proveedores​

Los colores de modelo conectan el gráfico diario, el calendario anual de actividad, la tabla de modelos y las barras de proveedores. Nombres, valores e indicadores de selección acompañan a los colores. El calendario de actividad abarca siempre los últimos 365 días, con independencia del intervalo elegido; el color de cada día identifica su modelo más usado.

El gráfico diario alterna entre Llamadas y Tokens. Pasa el puntero por un modelo en la leyenda o llévale el foco del teclado para trazar su línea. Selecciónalo para mantenerlo resaltado, vuelve a seleccionarlo para soltarlo o elige Mostrar todos los modelos para reiniciar. La tabla de modelos también ofrece una acción de resaltado. El resaltado cambia el énfasis sin alterar los totales diarios, los valores de la tabla ni los totales por proveedor.

Mueve el puntero por el gráfico o usa Explorar el uso diario para inspeccionar el total de un día y su desglose por modelo. El deslizador diario admite teclado: las flechas se mueven entre días e Inicio/Fin llegan al primero y al último. Los intervalos diarios y sus etiquetas usan UTC.

De forma predeterminada, el gráfico muestra los 12 nombres de modelo con más llamadas del periodo elegido, también en la vista de tokens. Cualquier modelo sigue siendo inspeccionable: enfoca o selecciona un modelo en la tabla o en el detalle del proveedor para cargar su línea diaria exacta, aunque quede fuera de esos 12. Un mensaje de carga nombra el modelo solicitado mientras se obtiene su historial.

La línea de un modelo adicional se separa de Otros modelos, y el grupo restante excluye sus llamadas, tokens comunicados y fallos. El gráfico contiene como mucho 13 líneas de modelo con nombre más el grupo restante, y sus valores diarios siguen cuadrando con los mismos totales. Elige Mostrar todos los modelos para volver a la vista predeterminada.

Las líneas diarias combinan llamadas con el mismo nombre de modelo registrado en distintos proveedores. La tabla de modelos conserva entradas separadas de proveedor/modelo, de modo que un mismo modelo puede aparecer bajo más de un proveedor. Los modelos con nombre conservan colores individuales en la tabla y en las barras de proveedores, incluidos los que quedan fuera del gráfico predeterminado.

El detalle de proveedores muestra la cuota de solicitudes de cada uno, una barra dividida por modelo, los tokens comunicados, las llamadas fallidas o canceladas y el tiempo medio de respuesta. La mezcla de capacidades sigue disponible bajo los desgloses de modelos y proveedores.

Los totales de tokens solo incluyen llamadas cuyo proveedor comunicó metadatos de uso. El porcentaje de cobertura hace visible la comunicación parcial; los recuentos que faltan nunca se estiman a partir de las solicitudes ni de otro modelo. Un periodo sin tokens comunicados muestra una explicación en la vista de Tokens, y su historial de solicitudes sigue disponible en Llamadas.

El endpoint incluye puntos diarios por modelo en modelSeries. Un parámetro de consulta model opcional solicita un nombre de modelo registrado exacto junto a los 12 principales, por ejemplo GET /api/plugins/usage?days=30&model=<encoded-model-name>. Es el mismo endpoint de solo lectura y exclusivo de administradores: consulta el registro de uso local y nunca llama a un proveedor de modelos para recuperar historial.

Un parámetro to opcional fija el límite final de la solicitud en una marca de tiempo Unix en milisegundos. Requiere model y solo acepta un entero seguro no negativo que no sea posterior a la hora actual del servidor. El navegador envía el range.to de la vista general al cargar un modelo individual, preservando sus límites UTC de día y año y excluyendo las llamadas posteriores a esa marca. Sin to, el endpoint usa la hora actual.

Cargar un modelo mantiene las tarjetas, la tabla, los totales por proveedor y los colores de la vista general. Su línea diaria solo se añade cuando los límites temporales y los totales diarios de la respuesta coinciden con esa vista general. El límite temporal no congela la base de datos: si rellenos históricos o borrados cambian esos totales, el navegador actualiza la vista general antes de mostrar la línea del modelo.

Si un servidor antiguo omite modelSeries, el gráfico muestra la serie agregada Todos los modelos con una explicación de que el desglose por modelo no está disponible. La tabla de modelos sigue disponible; el navegador no deduce el historial diario por modelo a partir de los totales del periodo ni del calendario anual.

No existe un interruptor para desactivar la medición. Como los datos se agregan entre cuentas, su consulta está restringida a administradores.

La página muestra llamadas, unidades, tokens, latencia y resultados. Añade Gobernanza de costes cuando se necesiten tarifas con vigencia, desglose de gasto, presupuestos, alertas o exportación contable. Los eventos sin tarifa coincidente o sin uso comunicado permanecen visiblemente sin precio en lugar de tratarse como gratuitos.

Atribución de OpenRouter​

Desde 0.18.0, las solicitudes a OpenRouter identifican la aplicación mediante sus cabeceras de atribución (HTTP-Referer: https://librewebui.org, un título y pistas de categoría). Solo se envían al propio https://openrouter.ai, nunca a una ruta personalizada o autoalojada, y no añaden nada a lo almacenado localmente.

Documentación relacionada​