Comando docker logs: 7 trucos para localizar problemas en contenedores

docker logs payment-service — pulsas Enter y la pantalla se llena de miles de líneas INFO. El servicio de pagos acaba de caer en producción, y el ERROR que necesitas está enterrado en algún punto de ese torrente de logs.

Demasiados logs en pantalla, monitorización en tiempo real, filtrar por intervalo de tiempo, localizar errores rápidamente: estos problemas son más difíciles de lo que parece cuando importa de verdad. Este artículo comparte 7 trucos prácticos de docker logs, de lo básico a lo avanzado, para ayudarte a localizar problemas en contenedores con rapidez.

Visualización básica de logs

1. La consulta más básica

Empecemos por lo elemental. Seguro que has visto este comando:

docker logs <nombre-contenedor>
# o con el ID del contenedor
docker logs abc123def456

Este comando vuelca en la terminal todos los logs desde el arranque del contenedor. Suena bien, pero en la práctica — vaya, los logs caen como una cascada y no se ve nada.

La primera vez que me pasó, el contenedor llevaba tres días en marcha y tenía decenas de miles de líneas. La terminal no paraba de desplazarse y, tras mirar un buen rato, ni un solo ERROR. Más tarde supe que en esos casos no debes usar este comando «a pelo».

¿Cuándo usar este comando básico?

Sinceramente, solo en dos situaciones:

• El contenedor acaba de arrancar y aún no hay muchos logs
• Necesitas exportar todos los logs a un archivo para hacer copia de seguridad

En cualquier otro caso, no lo uses. Hay mejores alternativas.

2. Ver las últimas N líneas

Este es el truco que más uso en el día a día:

docker logs --tail 50 my-container

El parámetro --tail muestra solo las últimas N líneas. Yo suelo usar 50 o 100: suficiente para ver el problema sin ahogarme en información.

Escenario real:

La semana pasada nuestro servicio API empezó a responder más lento. Mi primer instinto fue:

docker logs --tail 100 api-server

En las últimas 100 líneas vi de inmediato avisos de timeout de conexión a la base de datos. El alcance del problema se redujo al instante: no era el código, era la base de datos.

La idea central es: mira primero los logs recientes para acotar la dirección del problema. Si no encuentras pistas ahí, profundiza con otros métodos.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Por cierto, si quieres localizar el problema pero no sabes cuántas líneas necesitas, empieza con 50. Si no basta, sube a 100, y luego a 200. Ir paso a paso es mucho más eficiente que volcar todo de golpe.

Monitorización en tiempo real

3. Seguir el flujo de logs en vivo

Este truco es especialmente útil al depurar — como tail -f en Linux, monitoriza las actualizaciones de logs en tiempo real:

docker logs -f my-container

Con el parámetro -f (de follow), los logs siguen saliendo y las nuevas líneas aparecen al instante en pantalla.

Lo uso sobre todo en estos escenarios:

1. Monitorizar el arranque del contenedor
   Tras desplegar un servicio nuevo, arranco el contenedor y enseguida uso -f para observar los logs de inicio. Si hay un error en la configuración, lo ves al momento, sin esperar a que el servicio caiga.

2. Capturar el error en el momento
   ¿Un bug solo aparece con una acción concreta? Abro docker logs -f, reproduzco la acción y el error queda registrado en vivo.

Hay una combinación aún más práctica:

docker logs -f --tail 100 my-container

Así ves las últimas 100 líneas de historial y sigues los nuevos logs. Al empezar, revisas qué pasó recientemente y luego observas lo que viene.

A propósito, recuerdo a un compañero que depuraba contenedores con -f y miró la pantalla media hora sin que saliera ni una línea — se había olvidado de que el contenedor ya estaba caído y no generaba logs nuevos. Antes de usar -f, confirma que el contenedor está en ejecución: docker ps.

Filtrado preciso

4. Filtrar por rango de tiempo

Es una de mis funciones favoritas. ¿Te ha pasado que el monitor te avisa de un error «a las 3 de la madrugada», pero tú lo ves por la mañana y los logs ya han acumulado miles de líneas más? ¿Cómo localizar ese momento concreto?

Usa los parámetros --since y --until:

# Ver logs desde un momento dado
docker logs --since "2025-12-18T03:00:00" my-container

# Ver logs en un rango de tiempo
docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T04:00:00" my-container

El formato de tiempo es ISO 8601, pero no hace falta memorizarlo al pie de la letra: Docker también acepta tiempo relativo:

# Ver logs de la última hora
docker logs --since 1h my-container

# Ver logs de los últimos 30 minutos
docker logs --since 30m my-container

# Ver logs desde ayer hasta ahora
docker logs --since 24h my-container

Caso real:

Una vez el servicio de pedidos cayó a las 4 de la madrugada. A las 9, al investigar, ya había 5 horas de logs acumulados. Ejecuté directamente:

docker logs --since "2025-12-18T03:30:00" --until "2025-12-18T04:30:00" order-service

Solo miré la hora alrededor del incidente y localicé al instante el stack trace por desbordamiento de memoria. Con el volcado completo habría tardado mucho más.

5. Mostrar marcas de tiempo

A veces ves un ERROR en los logs pero no sabes cuándo ocurrió, y no puedes cruzarlo con los datos del sistema de monitorización. Ahí entran las marcas de tiempo:

docker logs -t my-container

El parámetro -t antepone una marca de tiempo a cada línea, así:

2025-12-18T10:23:45.123456789Z [INFO] Server started
2025-12-18T10:23:47.234567890Z [ERROR] Database connection failed

Así sabes con precisión cuándo se generó cada log. Suele combinarlo con otros parámetros:

# Ver logs de los últimos 30 minutos con marcas de tiempo
docker logs -t --since 30m my-container

# Monitorizar en tiempo real con marcas de tiempo
docker logs -f -t my-container

Sobre todo al analizar rendimiento, las marcas de tiempo son muy útiles: ves exactamente cuánto tarda una petición de principio a fin y en qué paso se ralentiza.

6. Filtrar palabras clave con grep

¿Los logs están llenos de INFO y solo quieres ver ERROR? Filtra con grep:

docker logs my-container | grep "ERROR"

Solo se muestran las líneas que contienen «ERROR». Pero hay un truco que debes conocer:

¡A veces grep no funciona!

La primera vez me dejó perplejo: había ERROR en los logs del contenedor, pero grep no encontraba nada. Resulta que Docker puede enviar los logs a stderr (flujo de error estándar) en lugar de stdout (salida estándar), y el pipe | solo procesa stdout por defecto.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

La solución es redirigir stderr a stdout:

docker logs my-container 2>&1 | grep "ERROR"

2>&1 redirige stderr (descriptor de archivo 2) a stdout (descriptor 1), y grep captura todos los logs.

Combinaciones más útiles:

# Ver 10 líneas de contexto antes y después de ERROR
docker logs my-container 2>&1 | grep -C 10 "ERROR"

# Buscar error sin distinguir mayúsculas
docker logs my-container 2>&1 | grep -i "error"

# Ver los últimos 20 errores
docker logs -t my-container 2>&1 | grep -i "error" | tail -20

El parámetro -C 10 es especialmente útil: muestra 10 líneas antes y después de la coincidencia. A veces la línea ERROR sola no basta; necesitas el contexto para entender el flujo completo del problema.

Técnicas avanzadas

7. Ubicación física del archivo de log

Quizá no lo sabías, pero los logs del contenedor se guardan en archivos reales en el host. ¿Quieres saber dónde están? Usa este comando:

docker inspect --format='{{.LogPath}}' my-container

La salida suele ser algo como:

/var/lib/docker/containers/abc123.../abc123...-json.log

¿Para qué sirve?

1. Consultar el archivo directamente
   A veces docker logs presiona al daemon de Docker (sobre todo con logs muy grandes); leer el archivo puede ser más rápido:

   sudo tail -f /var/lib/docker/containers/abc123.../abc123...-json.log
   

2. Hacer copia de seguridad de logs
   ¿Necesitas archivar? Copia el archivo directamente:

   sudo cp /var/lib/docker/containers/abc123.../abc123...-json.log ./backup/
   

3. Analizar con herramientas más potentes
   Por ejemplo, abrir el archivo con vim y usar las funciones de búsqueda del editor, más flexibles que grep.

Ojo: el archivo está en formato JSON; cada línea va envuelta en un objeto JSON y puede verse algo confuso. Si solo quieres texto plano, docker logs sigue siendo más cómodo.

Exportar logs a archivo:

Si quieres una copia en texto plano:

docker logs my-container > container.log

Así obtienes texto plano, fácil de analizar o compartir.

Buenas prácticas en producción

8. Configurar rotación de logs (evitar llenar el disco)

Sinceramente, es la configuración que más se ignora en producción y, a la vez, la más importante.

Caso real desastroso:

Vi una vez un desastre memorable. Un contenedor llevaba meses en marcha, el archivo de log crecía sin control y acabó llenando el disco del host. Todos los contenedores del servidor cayeron, la base de datos no podía escribir y el sitio quedó inoperativo. Tardamos dos horas en descubrir que los logs habían ocupado todo el espacio.

¿Cómo evitarlo?

Configura la rotación de logs (log rotation). En /etc/docker/daemon.json añade:

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

Significado de los parámetros:

• max-size: máximo 10 MB por archivo de log
• max-file: conservar como máximo 3 archivos de log

Con esta configuración, cada contenedor ocupa como máximo 10 MB × 3 = 30 MB en logs. Al llegar a 10 MB, Docker crea un archivo nuevo; al superar 3 archivos, elimina el más antiguo.

Cómo aplicar la configuración:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Tras modificar daemon.json, reinicia el servicio Docker:

sudo systemctl restart docker

Nota: reiniciar Docker reinicia todos los contenedores; en producción elige una ventana de mantenimiento adecuada.

Configurar un contenedor concreto:

Si solo quieres rotación para un contenedor específico, indícalo al arrancarlo:

docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  my-image

Así no afectas al resto de contenedores.

9. Estrategia de gestión de logs en producción

Tras usar docker logs un tiempo, notarás un problema: con mucho volumen de logs, el comando se vuelve lento e incluso puede bloquear la terminal. docker logs ejerce presión considerable sobre el daemon de Docker.

Cómo decidir en producción:

• Proyectos pequeños (1-10 contenedores):

  • docker logs + rotación configurada = suficiente
  • Simple y directo, sin infraestructura extra

• Proyectos medianos o grandes (más de 10 contenedores o arquitectura de microservicios):

  • Necesitas un sistema de logs centralizado
  • Opción habitual: ELK (Elasticsearch + Logstash + Kibana)
  • Otras opciones: Loki, Fluentd, Splunk

¿Por qué los proyectos grandes no pueden depender solo de docker logs?

1. Rendimiento: consultar logs de varios contenedores a la vez sobrecarga el daemon de Docker
2. Agregación: en microservicios, una petición puede cruzar 10 servicios; los logs están repartidos en 10 contenedores, ¿cómo correlacionarlos?
3. Consulta histórica: docker logs solo muestra los logs actuales del contenedor; tras un reinicio, los antiguos desaparecen
4. Trabajo en equipo: ¿pedir a operaciones, desarrollo y QA que entren al servidor a ejecutar comandos? No es viable

Mi recomendación:

• ¿Acabas de aprender Docker? Céntrate en dominar docker logs
• ¿Proyecto personal o equipo pequeño? Configura la rotación y usa docker logs sin problema
• ¿Más de 10 contenedores en producción? Plantéate en serio un sistema centralizado
• ¿Arquitectura de microservicios? Los logs centralizados no son un lujo, son imprescindibles

Conclusión

Volviendo al escenario de las 3 de la madrugada del principio. Si me pasara hoy, haría esto:

1. Primero docker logs --tail 100 payment-service para ver los logs recientes
2. Si no hay pistas, filtro por tiempo: docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T03:30:00" payment-service
3. Combino marcas de tiempo y grep: docker logs -t payment-service 2>&1 | grep -i "error" | tail -20

Tres pasos, dos minutos como máximo, problema localizado.

Ese es el valor de dominar docker logs: no memorizar todos los parámetros, sino saber qué combinación usar en cada escenario.

Un recordatorio final: si tus contenedores corren en producción, configura la rotación de logs ahora. No esperes a que el disco se llene. Son pocas líneas de configuración, pero pueden salvarte.

Tarjeta de referencia rápida

# Consulta básica
docker logs <nombre-contenedor>                    # Ver todos los logs
docker logs --tail 50 <nombre-contenedor>         # Ver las últimas 50 líneas

# Monitorización en tiempo real
docker logs -f <nombre-contenedor>                # Seguir en vivo
docker logs -f --tail 100 <nombre-contenedor>     # Últimas 100 líneas y seguir

# Filtrado por tiempo
docker logs --since 1h <nombre-contenedor>        # Última hora
docker logs --since "2025-12-18T03:00:00" <nombre-contenedor>  # Desde un momento dado

# Búsqueda precisa
docker logs -t <nombre-contenedor>                           # Mostrar marcas de tiempo
docker logs <nombre-contenedor> 2>&1 | grep -i "error"      # Buscar errores
docker logs <nombre-contenedor> 2>&1 | grep -C 10 "error"   # Buscar con contexto

# Técnicas avanzadas
docker inspect --format='{{.LogPath}}' <nombre-contenedor>   # Ubicación del archivo de log
docker logs <nombre-contenedor> > log.txt                   # Exportar logs

Guarda esta tarjeta de referencia; la próxima vez que un contenedor falle, consúltala directamente.