Una tarea dice "En cola" (Kubernetes)
La cuota del workspace está llena. Mirá “Cuotas por workspace” y esperá a que termine otro pod, o subí OCTOPUS_TENANT_QUOTA_CPU_REQUESTS / _MEMORY_REQUESTS.
Infraestructura
Infraestructura es la vista del operador sobre la máquina donde corre Thulu: cuánta CPU, memoria y disco queda, qué contenedores (o pods, en Kubernetes) están corriendo y para qué workspace, cuántas corridas esperan lugar y cómo le va a la caché de dependencias de los sandboxes. Sirve para contestar “¿por qué no arranca?” antes de abrir una terminal en el servidor.
La ven sólo los admins del workspace operador, el que nombra OCTOPUS_OPERATOR_WORKSPACE en el daemon, porque muestra todos los workspaces de la instalación. En una instalación sin login la ve quien abra el panel. En la versión SaaS los clientes no la ven; para su consumo tienen Uso y costos.
Abrir la página
Sección titulada «Abrir la página»Entrá a “Configuración” (abajo en la barra lateral) y, en el grupo “Operación”, elegí “Infraestructura”. Si el link no aparece, no sos admin del workspace operador. La dirección es /infra/ y cada pestaña tiene la suya (/infra/#cache, /infra/#storage), así que podés guardar o pasar el link a una pestaña puntual.
La página se actualiza sola cada 5 segundos y lo dice arriba a la derecha (“Actualizado hace 8s”). Si la pestaña del navegador queda oculta, se pone “En pausa”; si el daemon deja de contestar, muestra los últimos datos con “No se pudo actualizar. Mostrando datos de hace …”. “Actualizar” fuerza una lectura.
Chequeo rápido
Sección titulada «Chequeo rápido»-
Mirá los cuatro números de arriba, que quedan visibles en todas las pestañas: “CPU” (con la carga y los hilos), “Memoria”, “Disco” (lo libre en el directorio de datos) y “Corridas de agentes” (cuántas corren y cuántas esperan lugar). La barra pasa a ámbar desde 75% y a rojo desde 90%.
Resumen: los cuatro números fijos arriba y la actividad de los últimos 15 minutos. El disco al 84% ya se pinta en ámbar. -
En “Resumen”, el panel “Actividad” grafica CPU, memoria, red y contenedores. Elegí “15m”, “1h” o “2h”. El historial vive en memoria del daemon: después de un reinicio dice “Mostrando los últimos 7 minutos, desde que arrancó el daemon”.
-
Más abajo, “Quién la usa” reparte la CPU y la memoria por tipo (agentes, sandboxes, chats, navegadores, servidores MCP, Thulu, y “Ajenos a Thulu” para lo que corre en el mismo motor sin que esta instalación lo haya arrancado). “Capacidad” compara lo que corre contra cada límite, con un campo para cambiarlo, y lista “Corriendo ahora” por agente, workspace y etapa.
Capacidad: un límite en 0 se lee "sin tope". Cada fila tiene su campo para cambiarlo.
Si los cuatro números están bien y una tarea igual no arranca, el problema suele estar en la tarea (credencial, repo, agente): mirá Corridas de agentes.
Las seis pestañas
Sección titulada «Las seis pestañas»| Pestaña | Qué muestra | Para qué la abrís |
|---|---|---|
| “Resumen” | Actividad, “Quién la usa”, “Capacidad” | Ver si hay lugar y quién lo ocupa |
| “Contenedores” (o “Pods” en Kubernetes) | Cada contenedor con tipo, workspace, agente y etapa, CPU, memoria, tiempo arriba y estado | Encontrar el que consume o el que quedó colgado |
| “Workspaces” | Totales de la instalación y una fila por workspace; en Kubernetes, “Cuotas por workspace” | Ver qué workspace usa la máquina hoy y cuánto gastó |
| “Almacenamiento” | Discos, directorio de datos por carpeta, Postgres y almacenamiento de Docker | Saber qué llena el disco |
| “Caché de dependencias” | Cómo salieron las instalaciones de los sandboxes, por proyecto y por workspace | Ver si la caché acierta o hay que arreglar un script |
| “Máquina” | Host (sistema, CPU, memoria, swap, red) y runtime (Docker o Kubernetes, nodos) | Datos del servidor sin entrar por SSH |
Encontrar qué contenedor consume
Sección titulada «Encontrar qué contenedor consume»-
Abrí “Contenedores”. El número al lado del nombre de la pestaña cuenta los que corren.
-
Filtrá con “Todos los tipos” (Agentes, Sandboxes, Chats, Navegadores, Servidores MCP, Thulu, Sistema, Ajenos a Thulu) o buscá por nombre, workspace o tarea en “Nombre, workspace o tarea”. Destildá “Sólo los que corren” para ver también los detenidos.
-
La tabla ya viene ordenada por CPU, de mayor a menor. Hacé clic en “Memoria” (o en cualquier otro encabezado) para ordenar por esa columna; un segundo clic invierte el orden. Debajo del porcentaje aparece cuántos núcleos usa, o qué parte de su límite de memoria.
La columna de tarea lleva a la tarea y la de workspace a la pestaña “Workspaces”. Los contenedores de agente, chat y sandbox tienen “Detener” al final de la fila. Detener un agente deja la corrida como detenida por vos y la tarea en su etapa, para relanzarla; detener un chat no corta la conversación: el próximo mensaje arranca un contenedor nuevo y retoma la sesión. Un contenedor de agente que ninguna corrida de la tarea lanzó se borra en vez de detenerse.
Ver qué workspace usa la máquina
Sección titulada «Ver qué workspace usa la máquina»“Workspaces” arranca con cuatro totales (workspaces, usuarios, proyectos, tareas) y sigue con una fila por workspace: plan, contenedores y agentes corriendo, CPU y memoria, “Corridas hoy”, “Disco”, “Tokens hoy” y “Costo hoy”. “Hoy” es el día UTC.
En Kubernetes aparece además “Cuotas por workspace”: por cada namespace de workspace, la CPU (en núcleos) y la memoria reservadas contra la cuota, el techo debajo (“Techo …”) y los pods. Es el panel que explica una tarea “En cola”. En Docker, en su lugar, una línea dice que las cuotas por workspace existen sólo en Kubernetes y que los topes de Capacidad valen para toda la instalación.
Cuando una tarea queda “En cola”
Sección titulada «Cuando una tarea queda “En cola”»En Kubernetes cada workspace tiene una cuota de recursos. Cuenta lo que cada pod reserva (CPU y memoria pedidas), no su techo. Con la configuración por defecto, un agente con su navegador reserva 1 CPU y 1,7 GiB, y un sandbox 0,5 CPU y 0,7 GiB. Cuando la cuota del workspace no tiene lugar para un pod nuevo, la corrida no falla: la tarea pasa a “En cola” y espera su turno.
-
Abrí la tarea. Al lado de la etapa dice “En cola”, y en “Actividad” aparece la tarjeta “Próxima corrida”, con el agente, la etapa y el motivo en palabras (“el workspace tiene reservadas 5,5 de 6 CPU y necesita 1 más”). Si el motivo no llegó, dice “Espera lugar para arrancar”. Thulu deja además un comentario de sistema que avisa que arranca sola y a los cuántos minutos se abandona. “Cancelar espera” la saca de la fila sin mover la tarea.
La tarjeta "Próxima corrida" dice qué espera y por qué. En esta captura, de una instalación Docker, el freno es el tope de agentes. -
En Infraestructura, la tarjeta “Corridas de agentes” suma las que esperan (“1 corrida esperando lugar”) y “Capacidad” agrega “N corridas esperan lugar en la cuota de su workspace”.
Cinco agentes corriendo y uno esperando lugar. 
Ningún límite de la instalación está lleno: la corrida espera por la cuota de Tienda online, que ya tiene 4 de los 5 agentes. -
En “Workspaces” > “Cuotas por workspace”, buscá el workspace y mirá qué recurso está lleno.
-
Esperá, o liberá lugar: cuando termina cualquier pod del workspace (otra corrida, un chat, un sandbox), la primera tarea de la fila vuelve a probar enseguida. Si ese aviso no llega, prueba sola cada 5 a 30 segundos.
Cómo se comporta la fila:
- Hay una fila por workspace y se respeta el orden de llegada. Un workspace lleno no frena a otro.
- Mientras espera, la corrida no ocupa lugar en el tope de agentes de la instalación.
- Mover la tarea a otra etapa cancela la espera, igual que “Cancelar espera” en la tarjeta.
- A los 120 minutos (
agent.max_queue_minutes, hasta 720) se abandona: la tarea queda fallida con el último rechazo. - Las menciones a un agente y el auditor esperan en la misma fila y avisan en su hilo o en la tarea.
- Si el daemon se reinicia, relanza las corridas de etapa que estaban en cola. Las que retomaban algo (una respuesta, un mensaje, cambios pedidos) no se pueden reconstruir: la tarea vuelve a su estado anterior y un comentario pide reenviarlo.
En Docker no hay cuota por workspace: el freno es el tope de agentes de la instalación (agent.max_containers, sin tope por defecto) o el del plan del workspace. Una corrida que no entra pone la tarea “En cola” con la misma tarjeta, el motivo (“la instalación corre 4 de 4 agentes”) y “Cancelar espera”. En Infraestructura se ve como “N corridas esperando lugar” debajo de “Contenedores de agentes” y en la tarjeta “Corridas de agentes”.
Revisar la caché de dependencias
Sección titulada «Revisar la caché de dependencias»Cada workspace tiene una caché persistente (npm, Go, pip y las versiones de herramientas que instala mise) que comparten todos sus sandboxes, y cada proyecto puede tener snapshots de su instalación armados por el precalentado. Esta pestaña muestra si eso funciona. Cómo se configura el script de arranque está en Sandbox.
-
Abrí “Caché de dependencias” y elegí el rango: “7d”, “30d” o “90d”. Los datos se guardan 90 días y se actualizan cada minuto.
-
Leé “Para revisar”. Cada línea es una señal con su umbral:
Señal Cuándo aparece Caché que creció Más de 50% en el rango Disco de la caché lleno Más de 85% Pocos aciertos en un proyecto Menos de 50% con al menos 5 instalaciones Precalentado que falla 3 fallidos seguidos (en rojo) Claves de setup que cambian Más de 5 claves distintas en 7 días: los snapshots casi nunca coinciden Versión de mise sin uso Nadie la pidió en 30 días. Sólo aparece cuando el registro de instalaciones ya cubre 30 días -
Mirá las cinco tarjetas: “Aciertos” (instalaciones que terminaron en “Ya estaba” o “Desde snapshot”, sobre las que tienen fase de setup), “Instalaciones”, “Instalaciones completas”, “Tiempo ahorrado” (medido en esta instalación contra el promedio de una instalación completa) y “Caché usada”.
Arriba, las señales: app-mobile casi nunca acierta y backoffice-admin falló tres precalentados seguidos. -
En la tabla “Proyectos” de esta misma pestaña buscá la fila de la señal. El punto de color resume el estado; “Precalentado” dice “OK”, “Falló” o “N fallidos seguidos”. El nombre del proyecto, igual que cada señal, lleva al script de arranque en la página del proyecto.
Proyectos, caché por workspace (con qué guarda cada una) y versiones de mise con su último pedido. -
Para reintentar, tocá “Precalentar ahora” en la fila del proyecto: usa la revisión guardada del script y la tabla se actualiza en un minuto. Si el precalentado falla por el script, seguí el link al proyecto: el panel “Script de arranque” muestra el último precalentado y la causa.
Qué significa cada resultado de instalación en el gráfico “Instalaciones por día”:
| Resultado | Qué pasó |
|---|---|
| “Ya estaba” | El checkout ya tenía la instalación de esa clave; no corrió nada |
| “Desde snapshot” | Se restauró un snapshot del precalentado de la rama por defecto |
| “Instalado” | Corrió el setup completo, con las cachés tibias |
| “Falló” | Falló el setup o la instalación de herramientas |
Si un proyecto tiene pocos aciertos y muchas claves distintas, la clave de su caché depende de archivos que cambian en cada tarea. Revisá el campo “Lockfiles” del script de arranque: tiene que listar sólo los archivos que deciden la instalación, como package-lock.json (ver Sandbox).
Saber qué llena el disco
Sección titulada «Saber qué llena el disco»
“Almacenamiento” muestra cada disco que el daemon alcanza a ver (datos, raíz, Docker, Postgres) con su uso e inodos; el directorio de datos partido en proyectos, worktrees, adjuntos, logs y salida de corridas; el tamaño y las conexiones de Postgres con sus tablas más grandes; y, en Docker, imágenes, volúmenes, caché de build y los volúmenes más grandes. El directorio de datos y Docker se miden cada 10 minutos (“medido hace 7min 31s”).
Si falta un disco, abrí “¿Por qué falta un disco?”: el daemon sólo ve lo que su contenedor monta. Montalo y sumá la ruta a OCTOPUS_INFRA_DISK_PATHS.
Revisar la salud del daemon
Sección titulada «Revisar la salud del daemon»La página “Salud” (en el grupo “Operación” de Configuración) lista un chequeo por pieza: una por cada base del daemon (“Base de datos: tareas”, “Base de datos: acceso”, “Base de datos: sandbox”…), “Docker” y “Disco”, cada uno con su estado y latencia, más el tiempo activo y datos del proceso. Arriba, una píldora resume el estado general: “OK”, o “Degradado” si algo falla. El ícono de refrescar vuelve a consultar. Debajo está la licencia.
Cuando algo no arranca
Sección titulada «Cuando algo no arranca»Una tarea dice "En cola" (Docker)
El tope de agentes de la instalación o del plan del workspace está lleno, y la tarjeta de la tarea lo dice. La corrida arranca cuando termina otra; para darle más lugar, subí “Contenedores de agentes” en “Capacidad”.
Una corrida falla al instante por la cuota
El pod pide más que toda la cuota del workspace. El mensaje nombra el recurso y la variable que hay que subir.
El agente no consigue sandbox
Mirá “Sandboxes N de M” en “Capacidad”. Si está lleno, subí el límite ahí mismo o mirá en “Sandboxes” quién ocupa lugar. En Kubernetes, revisá que la cuota de CPU reservada alcance para agente y sandbox (1,5 CPU por tarea).
Disco en rojo o "Disco" en falla
Abrí “Almacenamiento” para ver qué carpeta o volumen crece. El chequeo “Disco” de Salud falla con menos de 1 GB libre en el disco desde donde corre el daemon.
Instalaciones lentas en el sandbox
Abrí “Caché de dependencias”: pocos aciertos o precalentados fallidos. El arreglo está en el script de arranque del proyecto.
Una pieza en falla en Salud
Una base que no responde aparece como “Base de datos: …” en falla con el error; “Docker” en falla significa que el daemon no llega al socket de Docker. Ver Operación self-hosted.
Mensajes de la propia página
Sección titulada «Mensajes de la propia página»| Mensaje | Qué pasa | Qué hacer |
|---|---|---|
| “Sólo el operador ve esta página” | No sos admin del workspace operador (vale también para miembros del operador que no son admins) | Usá Uso y costos o pedile a un admin del operador que la mire |
| “Tu rol no puede abrir esta página” | El daemon rechazó la lectura por rol sin decir que falta ser operador (por ejemplo, con un daemon más viejo) | Pedile a un admin del workspace operador que la mire o que te cambie el rol |
| “El inspector no está corriendo” | El daemon arrancó sin el inspector | Reinicialo y buscá en los logs por qué no arrancó |
| “Algunas fuentes no se pudieron leer…” | Docker, Kubernetes, métricas, Postgres o ajustes no respondieron | Los números de esa fuente quedan afuera; el aviso dice cuál |
| “No se puede leer el /proc del host” en CPU y Memoria | El daemon no ve /proc (macOS o un contenedor cerrado) |
Montá el /proc del host y apuntá OCTOPUS_INFRA_PROC_ROOT a esa ruta |
| “metrics-server no está instalado o no responde…” (Máquina) | Kubernetes sin metrics-server | Instalalo (k3s lo trae); mientras tanto se ven reservas y límites pero no el uso |
Límites que se ven en Capacidad
Sección titulada «Límites que se ven en Capacidad»| Fila | Clave | Default |
|---|---|---|
| “Contenedores de agentes” | agent.max_containers |
0, sin tope (SaaS: CPUs − 2, mínimo 2) |
| “Contenedores de menciones” | mention.max_containers |
3; 0 es sin tope |
| “Sandboxes” | sandbox.max |
3, mínimo 1 |
| “Contenedores de chat” | chat.max_containers |
5, mínimo 1 |
| “Espera máxima en la cola de agentes (minutos)” | agent.max_queue_minutes |
120, entre 1 y 720 |
Cada fila tiene su campo: escribí el número y tocá “Guardar”. Los topes valen para todos los workspaces de la instalación. Por API, la misma clave se cambia con PUT /settings/<clave> y una API key del workspace operador (ver CLI y Configuración). Las cuotas por workspace de Kubernetes (OCTOPUS_TENANT_QUOTA_*) son variables del daemon o values de Helm: ver Operación self-hosted.
Relacionado
Sección titulada «Relacionado»Uso y costosTokens y dólares por workspace, agente y tarea.
Corridas de agentesSeguir, frenar y relanzar una corrida.
SandboxScript de arranque, caché y precalentado.
Operación self-hostedVariables, cuotas y mantenimiento del servidor.