Logs de contenedores y cómo no perderlos

Cuando un servicio se cae, el log es la única fuente de verdad. Por defecto Docker lo escribe en un archivo junto al contenedor y no le pone ningún límite de tamaño: una aplicación que escribe mucho puede llenar todo el disco en una semana.

Cómo leerlo

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

Vale la pena recordar: Docker muestra lo que la aplicación escribe en la salida estándar y el error estándar. Si escribe en su propio archivo dentro del contenedor, docker logs no mostrará nada — tienes que buscar el log dentro o redirigir la salida.

docker compose exec app ls -la /var/log

Limita el tamaño ahora mismo

La configuración global para todos los contenedores es /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}

sudo systemctl restart docker

La configuración se aplica a los contenedores creados después de un reinicio. Los que están en ejecución deben recrearse. Para un solo servicio, lo mismo va en Compose:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

El resultado: no más de 60 MB por servicio en lugar de un crecimiento sin límite.

Comprueba el tamaño actual antes de que te sorprenda: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. No puedes recortar un archivo en ejecución con rm — el espacio no se libera mientras Docker mantiene el descriptor. La forma correcta: recrea el contenedor o sudo truncate -s 0 <file>.

Haz que los logs sobrevivan al contenedor

El archivo de log se elimina junto con el contenedor. Si el historial importa, entrégalo al journal del sistema:

logging:
  driver: journald
  options:
    tag: "myapp"

journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

journald rota los registros por su cuenta y está limitado por el ajuste SystemMaxUse en /etc/systemd/journald.conf. Para comprobar cuánto espacio ocupa: journalctl --disk-usage.

Para varios servicios a la vez es más cómodo recoger todo en un solo lugar — por ejemplo, con un contenedor recolector dedicado que guarda los registros en archivos por día. Pero empieza con journald: ya está ahí y no cuesta nada.

Qué buscar al depurar una caída

1. Las últimas 200 líneas antes del fallo: docker logs --tail 200 <container>.
2. Código de salida: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. El código 137 y true en OOMKilled significan que el kernel mató el proceso porque se quedó sin memoria — consulta límites de recursos.
3. El log del sistema de la máquina: sudo dmesg -T | tail -50 mostrará muertes por falta de memoria y errores de disco.

Errores comunes

• El disco se llenó de logs y todos los servicios se cayeron. Limitar el tamaño es obligatorio justo después de instalar Docker.
• Mirar el log de un contenedor ya eliminado. Después de docker compose down ya no está. Recoge los registros en journald de antemano.
• Secretos en el log. A las aplicaciones les encanta imprimir cadenas de conexión con contraseñas. Cualquiera con acceso a la máquina puede leer el log.
• Buscar el error en la consola de texto. Siempre es de 80×24 y las líneas largas se cortan. Para leer logs, SSH o la consola “Screen” son más cómodos.