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 locales de Ollama, incluidas las nativas de Chat y las de Work respaldadas por Ollama;
llamadas de chat de agentes CLI instalados;
chat mediante plugins, con y sin streaming;
embeddings, generación de imágenes, voz a texto, texto a voz, sonido y vídeo mediante plugins; y
llamadas de 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:

ID del proveedor o plugin y una 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)
recuentos de tokens, solo cuando el proveedor devuelve metadatos de uso
contadores adecuados a la capacidad (caracteres de TTS, imágenes, entradas de embeddings, trabajos de vídeo y bytes de audio)
duración de extremo a extremo y marca de tiempo
ID 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 y latencia media, un gráfico diario que alterna entre llamadas y tokens, tabla por modelo, cuota de tráfico por plugin y mezcla de capacidades. Los totales solo incluyen llamadas cuyo proveedor comunicó uso.

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.