Guía práctica: cómo reducir uso de disco por logs de contenedores Docker en VPS con rotación, compresión y retención sin perder trazabilidad
Por Kevin Marcondes · Publicado el · 8 min de lectura
¿Cómo reducir el uso de disco por logs de contenedores Docker en VPS combinando rotación, compresión y retención sin perder la capacidad de rastreo? Aquí tienes diagnóstico rápido, configuraciones seguras y cómo validar todo. El objetivo: limitar el crecimiento, comprimir eficientemente y conservar la información necesaria para auditoría y debugging sin sorpresas.
El problema: logs de contenedores llenando el disco de la VPS
Los logs en JSON pueden crecer sin control en /var/lib/docker/containers. En VPS con discos pequeños, unas pocas horas con DEBUG bastan para agotar el espacio y tumbar servicios. La buena noticia: se puede limitar el tamaño, comprimir y retener lo que importa sin sacrificar la investigación.
Antes de aplicar cambios, asegúrate de tener monitorización básica del filesystem y alertas. Si aún no la tienes, consulta una base con Prometheus y Grafana en Docker en Cómo configurar Prometheus y Grafana con Docker Compose.
Causas principales y cómo diagnosticar el volumen actual
En la mayoría de los casos, el driver por defecto json-file escribe stdout/stderr sin rotación configurada. Aplicaciones verbosas, niveles de log altos y errores en loop disparan el volumen.
Ejecuta un diagnóstico rápido para mapear quién ocupa espacio y dónde actuar primero:
- Driver json-file sin límites (max-size/max-file).
- Aplicaciones con DEBUG/TRACE activado en producción.
- Fallas con retries en bucle generando logs duplicados.
- Falta de centralización y retención externa a la VPS.
# Espaço do filesystem
df -h /
# Maiores arquivos de log por container
sudo du -h /var/lib/docker/containers/*/*-json.log | sort -h | tail -n 20
# Uso de espacio por imágenes/containers/volumes
docker system df
# Tamanho total de logs por container (agrupado)
sudo find /var/lib/docker/containers -name "*-json.log" -printf '%s %p\n' | awk '{print $1, $2}' | sort -n | tail -n 20
Estrategia segura: rotación, compresión y retención equilibradas
Para quien busca reducir uso de disco por logs de contenedores Docker en VPS con rotación, compresión y retención sin perder trazabilidad, el enfoque por capas funciona mejor.
El objetivo es limitar el crecimiento, reducir el coste en disco y preservar trazas de auditoría útiles. Combina políticas locales con retención externa cuando sea necesario.
- Rotación y retención en el propio Docker (por tamaño y número de archivos).
- Compresión de los archivos ya rotados para ahorrar espacio.
- Políticas de retención alineadas con los requisitos de auditoría del equipo.
- Opcional: centralización (p. ej. Fluentd/Elasticsearch o Loki) para búsquedas y retención a largo plazo. Véase Fluentd y Elasticsearch: logs PHP en VPS.
Implementación con json-file: rotación y retención nativas
Define límites globales en el daemon de Docker para el driver json-file. Esto controla el tamaño máximo por archivo y la cantidad de archivos rotados por contenedor. Ajusta los valores según tu perfil de tráfico.
Tras guardar, recarga Docker. En Compose también es posible definir logging.driver y logging.options por servicio si necesitas excepciones puntuales.
- Archivo: /etc/docker/daemon.json
- Recargar: sudo systemctl reload docker (o restart si es necesario).
- En Compose: logging: driver: "json-file" con opciones equivalentes.
{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "5"
}
}
Compresión automática de los rotados (ahorro real de espacio)
Docker no comprime los archivos rotados. Para ello, automatiza la compresión con un script y un systemd timer. La regla que proponemos comprime archivos a partir de .2, preservando el más reciente (.1) para inspecciones rápidas.
Atención: no uses logrotate para rotar estos archivos de nuevo. Aquí solo comprimimos los que Docker ya rotó.
# /usr/local/bin/compress-docker-logs.sh
set -euo pipefail
# Comprime logs já rotacionados (do .2 em diante) maiores que 1MB
find /var/lib/docker/containers -type f \
-regex ".*\-json\.log\.[2-9][0-9]*$" -size +1M -print0 | xargs -0 -r gzip -9
# Unidade systemd: /etc/systemd/system/compress-docker-logs.service
[Unit]
Description=Compress rotated Docker JSON logs
[Service]
Type=oneshot
ExecStart=/usr/local/bin/compress-docker-logs.sh
# Timer: /etc/systemd/system/compress-docker-logs.timer
[Unit]
Description=Run Docker logs compression periodically
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target
# Ativar
sudo systemctl daemon-reload
sudo systemctl enable --now compress-docker-logs.timer
Alternativas: driver local, journald o centralización
Dependiendo de tu escenario, otras opciones pueden reducir aún más el uso de disco o mejorar las consultas. Compara rápidamente antes de decidir. Para retención larga y búsquedas complejas, prioriza mover los logs fuera de la VPS a una stack centralizada.
| Opción | Rotación/Retención | Compresión | Pros | Contras/Observaciones |
|---|---|---|---|---|
| json-file (con max-size/max-file) | + fácil, por tamaño/cantidad | Vía script externo | Simplicidad, punto de entrada | Archivos JSON grandes; compresión separada |
| local (driver Docker) | Por tamaño/cantidad | No aplica (formato binario) | Más eficiente en espacio que JSON | Menos legible sin docker CLI |
| journald (driver) | Por la política de journald | Compresión interna | Integración con journalctl | Depende de la configuración global del sistema |
| Centralización (Fluentd/Elasticsearch o Loki) | En la stack central | En la stack central | Búsqueda y retención a largo plazo fuera de la VPS | Más componentes; requiere operación dedicada |
Garantizar trazabilidad al limitar y comprimir logs
Reducir espacio no puede romper las investigaciones. Conserva lo esencial para reconstruir eventos y correlacionar peticiones. En entornos auditados, define una ventana mínima de retención local y traslada el historial a una stack central.
- Log estructurado (JSON) con timestamp en UTC y nivel de log.
- Correlation ID en cada petición y propagación entre servicios.
- Incluye service, version/tag y container_name en los logs.
- Evita DEBUG en producción; adopta INFO y WARN/ERROR bien categorizados.
- Alertas de uso de disco y crecimiento anómalo de logs en la checklist de seguridad para VPS.
Verificación y solución de problemas comunes
Tras aplicar las políticas, valida si rotación y compresión están activas y si los contenedores usan el driver previsto. Si algo falla, revisa los puntos siguientes antes de revertir.
Si tu VPS ya está crítica, libera espacio con cuidado. HAZ backup de lo que necesites conservar antes de eliminar archivos. También revisa una estrategia de snapshots y backups incrementales en Snapshots LVM + Restic en S3.
Este checklist cierra el ciclo para reducir uso de disco por logs de contenedores Docker en VPS con rotación, compresión y retención, manteniendo espacio libre y trazabilidad.
- Contenedores antiguos pueden mantener configuraciones de logging propias; recréalos.
- Compose puede sobrescribir el daemon.json; alinea las opciones.
- copytruncate en logrotate puede perder registros; prefiere rotación nativa de Docker.
- Si no hay nuevos archivos .1, la rotación no ocurrió: revisa max-size.
- Evita comprimir .1 para inspección rápida de incidentes recientes.
# Conferir driver e opções de logging de um container
CONTAINER=myapp
docker inspect -f '{{.HostConfig.LogConfig.Type}} {{json .HostConfig.LogConfig.Config}}' "$CONTAINER"
# Ver rotacionados e compactados
ls -lh /var/lib/docker/containers/*/*-json.log*
# Forçar alguns logs e observar rotação
docker logs -f "$CONTAINER" & sleep 2; pkill -f "docker logs -f"
Preguntas frecuentes
¿Qué valores usar para max-size y max-file en Docker?
Depende del volumen de logs y del tamaño del disco. Empieza con un tamaño moderado por archivo y pocos archivos rotados. Monitoriza durante una semana y ajusta. Lo importante es mantener margen de seguridad en el filesystem y no perder eventos relevantes.
¿Puedo borrar manualmente los archivos *-json.log.1, .2, etc.?
Puedes, pero con precaución y, si es posible, después de asegurar que la rotación y compresión funcionan. Si borras manualmente, elimina solo los rotados (.1, .2...), nunca el archivo activo. Conserva backups de lo necesario para auditoría.
¿Es obligatorio usar logrotate para la compresión?
No. Puedes usar un script con systemd timer para comprimir solo los archivos rotados por Docker, evitando conflictos. logrotate es útil cuando él mismo realiza la rotación, pero con Docker es mejor dejar la rotación al driver y solo comprimir después.
¿Cambiar al driver local ayuda a ahorrar espacio?
En muchos escenarios, sí. El driver local almacena en formato binario más compacto que JSON y respeta políticas de rotación por tamaño y cantidad. Evalúa en un entorno de prueba, valida las herramientas de lectura y monitoriza uso de CPU e I/O.
¿Estas políticas afectan el rendimiento de los contenedores?
En general, el impacto es bajo. Tamaños muy pequeños pueden causar rotaciones frecuentes y más I/O. La compresión con gzip -9 consume CPU; ejecútala por timer y evita horarios de pico. Observa métricas de CPU, disco y latencia tras habilitar las políticas.
¿Cómo garantizar trazabilidad después de la compresión?
Mantén logs estructurados con timestamps precisos e IDs de correlación. Conserva al menos un archivo rotado no compactado (.1) para inspección rápida. Para investigaciones antiguas, almacena y consulta en la solución central de logs fuera de la VPS.
¿Quieres reducir espacio de logs sin perder trazabilidad?
Si necesitas adaptar políticas de rotación, compresión y retención a tu entorno Docker, hablemos de tu contexto y diseñemos un plan seguro.
Hablar sobre mi entorno DockerVer también
- 502 Bad Gateway intermitente en Docker Compose con Nginx y PHP‑FPM: cómo diagnosticar y corregir timeouts y exceso de conexiones
- Cómo diagnosticar y capturar paquetes por intermitencias de red entre contenedores Docker en Debian
- Cómo detectar y corregir inconsistencias de SKUs duplicados entre WooCommerce y ERP sin perder pedidos
- Cómo resolver el error 'Too many open files' en Linux en servidores PHP‑FPM durante picos de carga