Rotación de logs de OpenClaw y control del crecimiento en disco
Los logs de OpenClaw crecen porque el agente guarda transcripciones, llamadas a herramientas y sus salidas; se controlan con rotación (logrotate o retención nativa), compresión y un tope de tamaño para contenedores, más una alerta de disco.
En esta página
Por qué crecen tanto los logs de OpenClaw
En instalaciones autoalojadas, el agente escribe mucho más que un servidor web típico: registra cada turno de conversación, cada invocación de herramienta y el resultado completo de esa herramienta. Ahí dentro van bloques de código, respuestas de API y volcados de archivos. Un uso intensivo genera cientos de megabytes al día sin que nadie lo note.
- Trazas JSONL por sesión: una línea por evento, con el payload entero.
- Salidas de herramientas: lecturas de ficheros, respuestas HTTP y errores con stack trace.
- Nivel de detalle alto: el modo depuración multiplica el volumen por varias veces.
- Sin política por defecto: muchos despliegues arrancan sin límite de retención ni compresión.
La rotación de logs es el proceso de cerrar, comprimir y archivar periódicamente los archivos de registro para que no ocupen el disco de forma indefinida. Sin ella, un agente conversacional activo puede agotar el volumen en pocas semanas.
El plan detrás de Hosting Notes
El mismo VPS de 4 GB y stack LiteSpeed que medimos en estas guías.
Diagnóstico rápido: dónde se va el espacio
Antes de tocar configuración, mide. Estos comandos te dan la foto en menos de un minuto:
df -h
sudo du -xh /var/log --max-depth=2 | sort -h | tail -20
sudo find / -xdev -type f -size +200M -exec ls -lh {} \; 2>/dev/null
journalctl --disk-usageSi el directorio de OpenClaw está fuera de /var/log, apunta la búsqueda a su ruta real. Revisa también el espacio ocupado por imágenes Docker con docker system df: los log drivers de contenedor son una causa habitual de crecimiento invisible.
Rotación con logrotate paso a paso
logrotate es la herramienta estándar en Linux y no requiere reiniciar el agente si usas copytruncate. Crea un archivo en /etc/logrotate.d/openclaw:
/var/log/openclaw/*.log {
daily
rotate 14
missingok
notifempty
compress
delaycompress
copytruncate
su openclaw openclaw
}Qué hace cada directiva clave: rotate 14 conserva dos semanas; compress reduce el texto plano a una fracción de su tamaño; delaycompress evita comprimir el archivo que el proceso aún puede estar escribiendo.
| Método | Cuándo usarlo | Riesgo |
|---|---|---|
copytruncate | El proceso no reabre el archivo al recibir una señal | Puede perder las líneas escritas durante la copia |
create + postrotate | El servicio soporta recarga o reinicio limpio | Requiere conocer el nombre exacto de la unidad systemd |
| Retención nativa de la app | La versión la soporta y quieres cero piezas extra | Menos control sobre compresión y granularidad |
Verifica la sintaxis antes de esperar al cron diario: sudo logrotate --debug /etc/logrotate.d/openclaw. Y fuerza una prueba real con -f.
Retención nativa y nivel de detalle
Si tu build de OpenClaw expone ajustes de retención (días o tamaño máximo por sesión), actívalos: es la vía más limpia porque el propio proceso decide qué borrar. Los nombres exactos de las claves cambian entre versiones, así que consulta el archivo de configuración de tu instalación en lugar de copiar valores de un tutorial ajeno.
Complementa con higiene de verbosidad:
- Deja el nivel
infoen producción y sube adebugsolo mientras investigas un fallo. - Separa logs de aplicación y de auditoría: la auditoría se conserva más tiempo, la traza técnica se puede purgar antes.
- Programa una purga puntual de sesiones antiguas en lugar de borrar a mano cuando el disco ya está al 95 %.
Nota
No borres el archivo de log activo con rm mientras el proceso lo tiene abierto: el espacio no se libera hasta que el proceso muere. Usa truncate -s 0 o la rotación correspondiente.
Contenedores y systemd: los otros dos grifos
Si ejecutas OpenClaw en Docker, el driver json-file guarda la salida estándar sin límite por defecto. Pon un tope en el servicio:
services:
openclaw:
logging:
driver: json-file
options:
max-size: "50m"
max-file: "5"Eso acota el consumo por contenedor a un valor predecible. Para systemd, limita el journal en /etc/systemd/journald.conf con SystemMaxUse= y MaxRetentionSec=, y aplica los cambios con systemctl restart systemd-journald.
Un VPS con disco modesto y NVMe es un buen sitio para este tipo de agente, siempre que el almacenamiento esté dimensionado y monitorizado; los planes de Hostinger permiten elegir el tamaño de disco según el uso previsto. Revisa la política de ampliación antes de migrar, porque el crecimiento de logs es acumulativo, no puntual.
Presupuesto de disco y alertas
La rotación sin vigilancia solo retrasa el problema. Reserva entre un 15 % y un 20 % del volumen libre y avisa cuando baje de ahí. Un script mínimo en cron resuelve el 90 % de los sustos:
#!/bin/sh
USO=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$USO" -ge 80 ] && echo "Disco al ${USO}% en $(hostname)" | mail -s "Alerta disco" [email protected]Añade una comprobación externa de disponibilidad y otra del tamaño del directorio de logs. Con rotación diaria, retención de dos semanas y alerta al 80 %, el crecimiento deja de ser un incidente y pasa a ser una métrica más.
¿Listo para empezar? Consulta los planes de Hostinger.