Aurora Libros está construida, optimizada y endurecida. Falta lo que separa una plataforma que funciona de una plataforma que se puede operar: saber qué está pasando ahora mismo, qué pasó anoche a las 3:14 y por qué el contenedor de la API se reinició cuatro veces el martes.

1. La regla de stdout/stderr, revisitada
2. Los drivers de logging
3. Configuración global y por servicio
4. Rotación obligatoria: el cálculo del disco lleno
5. Logs estructurados en JSON
6. Agregación centralizada: el patrón
7. Loki, Promtail y Grafana en el perfil observabilidad
8. Consultas LogQL útiles
9. Métricas: docker stats y sus límites
10. La API de métricas del daemon
11. cAdvisor, node-exporter y Prometheus
12. Las métricas que de verdad se vigilan
13. Alertas
14. El endpoint de salud rico
15. Trazas distribuidas: el siguiente paso

Una aplicación en contenedor no escribe ficheros de log: escribe en la salida estándar y en la de error, y deja que la plataforma haga el resto.

El motivo es concreto: el contenedor es efímero. Un fichero en /var/log/app.log desaparece al recrearlo, obliga a montar un volumen solo para eso, exige rotación propia y no puede consultarse con docker logs. Escribiendo a stdout, el proceso solo produce los eventos; recogerlos, rotarlos y enviarlos a donde toque es responsabilidad del driver de logging.

Las salidas del proceso son tuberías hacia el daemon, no ficheros. Al otro extremo, el driver decide su destino.

La limitación marcada como "No" es importante y sorprende en el peor momento: con syslog, fluentd, gelf o awslogs, docker logs deja de funcionar. Si el sistema central está caído, te quedas sin ninguna vía para ver qué pasa.

La estrategia habitual evita ese callejón: dejar json-file o local con rotación y recoger los ficheros con un agente externo (Promtail, Fluent Bit, Vector). Así conservas docker logs para el diagnóstico inmediato y tienes agregación central para el histórico.

El valor por defecto para todo el host va en /etc/docker/daemon.json, y lo específico en Compose:

Tras sudo systemctl restart docker, verifícalo con docker info --format '{{.LoggingDriver}}'. Ojo: cambiar el driver solo afecta a los contenedores creados después; los existentes conservan el suyo hasta que se recreen.

Sin rotación, json-file crece sin límite. Hagamos el cálculo con Aurora Libros: la API registra una línea por petición, unos 200 bytes en JSON, con 50 peticiones por segundo en hora punta y una media de 15/s a lo largo del día.

Casi 8 GB al mes de un solo servicio, en un fichero que nunca se trunca. Con cuatro servicios y un disco de 40 GB, la plataforma se cae por disco lleno en menos de dos meses. Y el fallo por disco lleno es especialmente desagradable: PostgreSQL deja de aceptar escrituras, Docker no puede crear contenedores y el propio sistema de logs no puede registrar el problema.

Con max-size: 50m y max-file: 5, el techo por contenedor son 250 MB, y siempre tienes los últimos días. Dos avisos: max-file sin max-size no hace nada, y el driver local trae rotación activada por defecto (100 MB en 5 ficheros), lo que lo convierte en la opción más segura si te olvidas de configurarla.

Un log en texto libre obliga a escribir expresiones regulares para todo. Un log en JSON se consulta por campos.

El req_id es la pieza clave: se propaga por la cabecera x-request-id, lo devuelve la respuesta y aparece en todas las líneas de esa petición. Cuando un usuario reporta un error a las 10:14 con ese identificador, recuperas la traza completa de su petición con una sola consulta, en lugar de leer diez mil líneas.

docker logs sirve para un contenedor de una máquina. Con varios servicios, varios nodos y contenedores que se recrean, hace falta que los eventos salgan del host y vivan más que el contenedor que los produjo.

Loki indexa solo las etiquetas (servicio, nivel, host) y comprime el resto, lo que lo hace mucho más barato que una pila que indexa cada palabra. Las alternativas: ELK/OpenSearch (Elasticsearch + Logstash + Kibana), más potente en búsqueda de texto completo y bastante más exigente en recursos; y los servicios gestionados de las nubes.

Que todo esto viva en un perfil (lección 04-06) es deliberado: docker compose up -d sigue levantando solo la plataforma, y la observabilidad se añade cuando se necesita, sin consumir recursos en el portátil de nadie.

Aviso de seguridad. Promtail monta docker.sock en solo lectura para leer etiquetas, y cAdvisor tiene acceso amplio al host. Son concesiones reales (lección 05-03): en producción, usa un proxy de socket filtrado y valida esta configuración con tu responsable de seguridad.

La segunda consulta es la que justifica todo el trabajo del apartado 5: con un identificador que te da el usuario, recuperas su petición exacta entre millones de líneas en menos de un segundo. La última convierte una decisión de arquitectura —el patrón cache-aside— en una métrica observable: si la proporción de aciertos cae, algo pasa con Redis o con la invalidación.

Sus límites, y por eso no basta: es una instantánea sin histórico, no tiene alertas, no agrega varios hosts y hay que estar mirando. Sirve para "qué está pasando ahora"; no para "qué pasó anoche".

El propio daemon expone métricas en formato Prometheus si lo habilitas en daemon.json:

Son métricas del daemon, no de cada contenedor: cuántos contenedores hay en cada estado, tiempos de las operaciones, versión del motor. Útiles para vigilar la salud del propio Docker. Y expón ese puerto solo en la red de gestión: no lleva autenticación.

cAdvisor lee los cgroups (lección 05-07) y publica métricas por contenedor; node-exporter hace lo propio con el host.

Grafana consulta ambas fuentes, y los paneles no hay que inventarlos: los dashboards 193 (Docker/cAdvisor) y 1860 (Node Exporter Full) del catálogo público cubren el 90 % de lo necesario.

Fíjate en el patrón: lo que importa casi nunca es el valor absoluto, sino la relación con el límite que pusiste en la lección 03-07. 400 MB de memoria no dicen nada; 400 MB sobre un límite de 512 MB dicen que falta poco para un OOM.

Las dos claves de una alerta que no acaba ignorada. La primera es for: sin él, un pico de dos segundos despierta a alguien de madrugada. La segunda es a quién notifica: guardia para lo que exige acción inmediata (servicio caído, errores masivos) y equipo para lo que puede esperar a mañana (memoria alta, reinicios). Una alerta que no lleva a ninguna acción concreta debe borrarse; el peor estado posible de un sistema de alertas es que el equipo las ignore por costumbre.

/salud empezó devolviendo {"estado":"ok"}. Eso solo dice que el proceso arranca. Un endpoint útil comprueba sus dependencias:

El 503 es lo importante: el HEALTHCHECK del Dockerfile lo detecta, el contenedor pasa a unhealthy, depends_on: service_healthy no arranca lo que dependa de él y el balanceador deja de enviarle tráfico. Con un /salud que solo devolvía ok, nada de eso ocurriría.

Un matiz de diseño: distingue liveness (¿debe reiniciarse este proceso?) de readiness (¿puede recibir tráfico?). Si Redis cae, la API no debe reiniciarse en bucle, solo dejar de anunciarse como lista; la distinción explícita llega con Kubernetes (lección 06-05).

Logs y métricas responden a "qué pasó" y "cuánto"; las trazas responden a "dónde se fue el tiempo". Una petición a /libros atraviesa nginx, Express, Redis y PostgreSQL, y una traza mide cada tramo por separado. OpenTelemetry es el estándar: con la instrumentación automática de Node basta un paquete y unas variables (OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT: http://tempo:4318, OTEL_TRACES_SAMPLER_ARG: "0.1" para muestrear el 10 %).

El req_id del apartado 5 es, de hecho, un precursor artesanal del trace_id. Si adoptas OpenTelemetry, sustitúyelo por el identificador de traza y tendrás logs, métricas y trazas correlacionados por el mismo campo.

Escribir logs a ficheros dentro del contenedor. Se pierden al recrearlo y docker logs no los ve. Siempre a stdout/stderr.

No configurar rotación. 8 GB al mes por servicio y una caída por disco lleno que además impide registrar la causa.

Cambiar el driver a fluentd o syslog y perder docker logs. Si el sistema central falla, te quedas ciego. Mantén json-file/local y recoge con un agente.

Registrar datos personales o secretos. Un log con contraseñas o datos de clientes es un incidente de protección de datos. Filtra en el emisor y consúltalo con tu responsable de compliance.

Alertar sobre valores absolutos, o alertar sin for. 400 MB no significa nada sin el límite al lado, y un pico de dos segundos que despierta a alguien de madrugada enseña al equipo a ignorar las alertas.

Un /salud que solo dice ok. No distingue "el proceso vive" de "el servicio funciona". Comprueba las dependencias.

Consejo: monta la observabilidad antes de necesitarla. El día del incidente no hay tiempo para instalar Prometheus, y los datos que más falta hacen son los de las horas anteriores, que ya nadie puede recuperar.

Ejercicio 1. Calcula el crecimiento de logs de aurora-api con tu propio tráfico: mide el tamaño del fichero de log, genera 500 peticiones, vuelve a medir y extrapola a un mes. Después configura la rotación y demuestra que el techo se respeta.

Ejercicio 2. Añade el req_id y el registro estructurado a aurora-api, genera tráfico y demuestra que puedes reconstruir la traza completa de una petición concreta a partir del identificador que devuelve la cabecera de respuesta.

Ejercicio 3. Levanta el perfil observabilidad, provoca un consumo de memoria cercano al límite en aurora-api y comprueba en Prometheus que la expresión de la alerta se dispara. Explica por qué la alerta usa una proporción y no un valor absoluto.

Solución 1.

Siete gigabytes al mes de un solo servicio, medidos y no estimados. Ahora el límite:

El techo se respeta: tres ficheros, ninguno por encima de 10 MB, 25 MB en total pase lo que pase. Se han perdido las líneas más antiguas, y eso es exactamente lo que se busca: los logs recientes son los que sirven para diagnosticar, y el histórico es responsabilidad de Loki, no del disco del host. El detalle a recordar es que max-size sin max-file limita un solo fichero y max-file sin max-size no limita nada: hacen falta los dos.

Solución 2.

Tres líneas que cuentan la historia completa de esa petición: la caché no tenía la clave, se consultó PostgreSQL con 9 filas en 24,8 ms, y la respuesta salió con un 200 en 33,2 ms totales. Con esos datos puedes afirmar que el 75 % del tiempo se fue en la base de datos, sin adivinar nada.

Lo que hace esto operable de verdad es que el identificador sale al exterior en la cabecera x-request-id. El usuario que reporta un problema puede darte ese código —o el frontal puede incluirlo en su mensaje de error—, y tú recuperas su petición exacta entre millones. Y como la cabecera también se acepta en la entrada, si nginx o el frontal ya generan uno, la API lo reutiliza y la traza queda encadenada de extremo a extremo.

Solución 3.

La expresión devuelve resultado (94 % del límite) y la alerta entra en pending. Tras cinco minutos cumpliendo la condición —el for: 5m de la regla— pasaría a firing y llegaría a Alertmanager. Ese retardo es deliberado: un pico de memoria durante una importación puntual no debe generar aviso; una tendencia sostenida al 94 %, sí.

Y la razón de usar una proporción y no un valor absoluto es doble. La primera, de significado: 480 MB es catastrófico para aurora-api (límite de 512 MB, a un paso del OOM killer y del código 137) y absolutamente normal para aurora-db (límite de 2 GB). Una alerta con umbral fijo o inunda de falsos positivos o no detecta nada. La segunda, de mantenimiento: el día que subas el límite de la API a 1 GB, la regla en proporción sigue siendo correcta sin tocarla, mientras que un umbral absoluto habría que recordar cambiarlo. Y ese "recordar" es justo lo que nunca ocurre.

Aurora Libros ya no es una caja opaca en marcha. Sabes por qué una aplicación en contenedor escribe a stdout/stderr y no a ficheros, conoces los ocho drivers de logging y la trampa que esconden la mitad de ellos: con syslog, fluentd o gelf, docker logs deja de funcionar, así que la estrategia sólida es json-file o local con rotación más un agente que recoja. Y has hecho el cálculo que convence a cualquiera: 214 bytes por petición son 7 GB al mes de un solo servicio, y sin max-size y max-file eso acaba en una caída por disco lleno que además impide registrar su propia causa.

Tu API emite ahora logs estructurados en JSON con nivel, servicio, versión y un req_id que viaja por la cabecera x-request-id y permite reconstruir la traza completa de una petición concreta entre millones de líneas. Sobre eso montas la agregación con Loki, Promtail y Grafana en un perfil observabilidad que no estorba en desarrollo, con consultas LogQL que van desde "errores de la última hora" hasta la proporción de aciertos de caché, que convierte una decisión de arquitectura en una métrica observable.

Del lado de las métricas conoces los límites de docker stats, el endpoint Prometheus del daemon, y cAdvisor y node-exporter alimentando a Prometheus y Grafana. Y sabes qué vigilar: memoria y CPU frente al límite —no en absoluto—, reinicios, salud, latencia p95, tasa de errores y disco; con alertas que llevan for y que distinguen a quién despiertan. Cierras con un /salud que comprueba PostgreSQL y Redis y devuelve 503 cuando algo falla, haciendo que el HEALTHCHECK, depends_on y el balanceador reaccionen solos, y con OpenTelemetry apuntado como siguiente paso.

En la lección 05-07, la última del módulo, se cierra el círculo: bajarás al kernel de Linux para ver que un contenedor no existe. Es un proceso normal con tres mecanismos encima —namespaces, cgroups y un sistema de ficheros de capas—, y los vas a tocar uno a uno: los siete namespaces con lsns y nsenter, los ficheros de cgroups v2 de aurora-db comprobando que coinciden exactamente con los límites que pusiste en 03-07, el montaje OverlayFS real con su copy-on-write, las capacidades descodificadas con capsh, y qué hace exactamente runc cuando arranca un contenedor.