Debian 13: Journald se comió tu disco — limitar logs sin perder lo importante

Guía de diagnóstico rápido

Esta es la secuencia de “suena el pager, el disco está al 98% y la aplicación lanza errores raros”. Quieres obtener señales en menos de cinco minutos. Haz esto en orden.

Primero: confirma dónde se fue el disco

• Revisa el sistema de archivos que está lleno y si es la ruta del journal (usualmente /var o la raíz).
• Mide /var/log/journal y /run/log/journal.
• Consulta la propia visión de uso de journald.

Segundo: identifica si es una tormenta de logs o retención

• Busca mensajes de limitación de tasa, fallos repetidos de unidades o un servicio muy ruidoso.
• Verifica la tasa de ingestión: recuentos de “últimos 5 minutos” por unidad.
• Comprueba si los logs son persistentes y qué tan grandes son los límites configurados.

Tercero: detén la hemorragia de forma segura

• Haz vacuum por tamaño o por tiempo (no borrados aleatorios), y asegúrate de no eliminar la única copia de los logs que necesitas.
• Aplica límites en journald.conf y reinicia journald.
• Corrige el servicio ruidoso. Si no, solo estarás barriendo agua con una escoba.

Broma #1: Los logs son como purpurina: geniales en manualidades, catastróficos en producción, y los encontrarás en lugares donde nunca deberían haber estado.

Qué está haciendo realmente journald con tu disco

systemd-journald recoge logs del kernel, de servicios y de cualquier cosa que escriba en stdout/stderr bajo systemd. Los almacena en un formato de journal binario. Eso te aporta indexado, campos estructurados y filtrado rápido. También te da la capacidad de llenar el disco a la velocidad de “alguien desplegó logging de depuración en un camino de código caliente”.

Persistente vs volátil: la silenciosa bifurcación

journald puede almacenar logs en almacenamiento en memoria respaldado por runtime (/run/log/journal) o en disco (/var/log/journal). En muchos servidores quieres logs persistentes, porque los reinicios ocurren—a veces a propósito. Pero los logs persistentes significan que debes establecer límites y retención, porque el disco es finito y los logs son ambiciosos.

Por qué “disco lleno” por logs rompe cosas no relacionadas

Cuando el sistema de archivos que contiene /var se llena, journald no es lo único que deja de poder escribir. Puedes ver fallos en instalaciones de paquetes, sesiones SSH que no pueden asignar ptys, bases de datos que se niegan a crear archivos temporales y servicios del sistema que fallan porque no pueden escribir estado. El primer problema es “los logs crecieron”. El segundo problema es “todo asume que puede escribir”.

Los controles de almacenamiento de journald son por defecto basados en porcentajes

journald puede imponer uso máximo en términos absolutos (SystemMaxUse=) y puede mantener buffers de espacio libre (SystemKeepFree=). Los valores por defecto pueden ser sorprendentemente permisivos para volúmenes pequeños, especialmente en VMs con discos raíz reducidos.

La rotación no es el problema; la retención sí

La gente piensa que “rotar logs” soluciona esto. journald ya rota internamente. Los desastres de disco ocurren cuando la retención es efectivamente “guardar todo hasta un límite que no sabías que era enorme”, o cuando la tasa de logs es tan alta que incluso un tope sensato se alcanza demasiado rápido—causando churn y pérdida de los mensajes más nuevos o más antiguos según tu configuración y la presión.

Hechos interesantes y contexto (para que dejes de pelear la guerra equivocada)

• Hecho 1: journald almacena logs en un formato binario con campos indexados, por eso journalctl _SYSTEMD_UNIT=foo.service es rápido comparado con hacer grep en archivos planos.
• Hecho 2: El almacenamiento persistente del journal requiere que exista /var/log/journal; si no existe, journald normalmente se queda en modo runtime bajo /run.
• Hecho 3: El formato del journal soporta características de integridad (como sealing) destinadas a detectar manipulación, pero esas características no reemplazan el registro centralizado.
• Hecho 4: syslog precede a journald por décadas y creció alrededor de archivos de texto append-only y forwarding remoto; journald nació asumiendo sistemas ricos en metadatos y conscientes de unidades.
• Hecho 5: Los kernels Linux pueden emitir avalanchas de mensajes si un driver o sistema de archivos se vuelve inestable; el ring buffer del kernel y journald pueden convertirse en cómplices involuntarios.
• Hecho 6: En sistemas muy ocupados, el logging en sí mismo se vuelve una característica de rendimiento—o un bug de rendimiento—porque cada línea de log es IO, CPU y contención en algún lugar.
• Hecho 7: Las plataformas de contenedores popularizaron “log a stdout”, lo que desemboca directamente en journald en hosts basados en systemd a menos que lo reencamines a otro sitio.
• Hecho 8: Los límites basados en porcentaje (como “usar hasta el 10% del sistema de archivos”) se comportan muy diferente en un volumen raíz de 20GB frente a un volumen de logs de 2TB, y los valores por defecto no conocen tu intención.

Una cita, porque sigue siendo la mejor consigna en operaciones: La esperanza no es una estrategia. — idea parafraseada frecuentemente atribuida a líderes en ingeniería y ops.

Tareas prácticas: comandos, significado de salidas, decisiones

Estos no son ejercicios de laboratorio. Son las cosas que haces cuando el disco está lleno, o está a punto de llenarse. Cada tarea incluye: un comando, qué te dice la salida y la decisión que tomas a continuación.

Tarea 1: Identificar qué sistema de archivos está realmente lleno

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/vda1      ext4    30G   29G  200M 100% /
tmpfs          tmpfs  3.1G  1.2M  3.1G   1% /run

Qué significa: La raíz está llena; journald en almacenamiento persistente probablemente vive bajo /var que aquí está en /. Tus escrituras están fallando globalmente.

Decisión: Ve de inmediato a medir los directorios del journal y a vaciarlos. También planifica un límite a largo plazo, o esto volverá a ocurrir.

Tarea 2: Medir directorios del journal por tamaño

cr0x@server:~$ sudo du -sh /var/log/journal /run/log/journal 2>/dev/null
18G	/var/log/journal
24M	/run/log/journal

Qué significa: El journal persistente es el que más pesa. El runtime es pequeño.

Decisión: Vacía el journal persistente; luego aplica límites en la configuración.

Tarea 3: Preguntar a journald cuánto espacio cree que usa

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 18.1G in the file system.

Qué significa: Esto confirma que la contabilidad de journald concuerda con lo que viste con du. Si no coincide, puede que estés ante archivos abiertos pero borrados u otras rutas de logs.

Decisión: Si este número es grande y crece rápido, necesitas tanto límites de retención como control de tasa/volumen en la fuente.

Tarea 4: Ver cómo está configurado journald (valores efectivos)

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=1month
RateLimitIntervalSec=30s
RateLimitBurst=10000

# /usr/lib/systemd/journald.conf
[Journal]
#Storage=auto
#SystemMaxUse=
#SystemKeepFree=

Qué significa: Puedes ver qué está establecido en /etc frente a los valores por defecto. Si no tienes límites explícitos, estás confiando en valores por defecto para que coincidan con la disposición de tu disco. Esa es una apuesta que usualmente pierdes.

Decisión: Pon límites explícitos en /etc/systemd/journald.conf (o en un drop-in) ajustados al disco y a las necesidades de cumplimiento.

Tarea 5: Confirmar que journald usa almacenamiento persistente y que la ruta correcta existe

cr0x@server:~$ sudo ls -ld /var/log/journal
drwxr-sr-x+ 3 root systemd-journal 4096 Dec 28 08:11 /var/log/journal

Qué significa: El directorio existe con el grupo esperado. Bien. Si no existiera, journald podría estar en modo runtime y perderías logs al reiniciar.

Decisión: Si requieres persistencia, asegúrate de que /var/log/journal exista y que el sistema tenga el grupo systemd-journal donde corresponda.

Tarea 6: Encontrar la unidad más ruidosa en los últimos 5 minutos

cr0x@server:~$ sudo journalctl --since "5 min ago" --output short-unix | awk '{print $6}' | sort | uniq -c | sort -nr | head
  8421 myapp.service:
  2103 kernel:
   611 sshd[1023]:
   222 systemd[1]:

Qué significa: myapp.service está spameando. El kernel también está hablador pero en segundo plano.

Decisión: Corrige el nivel de logging de la aplicación o el bug primero; luego ajusta la retención de journald como red de seguridad, no como control principal.

Tarea 7: Inspeccionar el contenido del spam (no adivines)

cr0x@server:~$ sudo journalctl -u myapp.service --since "15 min ago" -n 20
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1234
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1235
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1236

Qué significa: Esto es ruido a nivel debug en producción. No son “solo logs”; es un síntoma de un cambio o una mala configuración.

Decisión: Revierte la configuración, aplica un hotfix al nivel de logging o añade muestreo. No “vacíes más fuerte”.

Tarea 8: Comprobar si journald está limitando la tasa (y perdiendo mensajes)

cr0x@server:~$ sudo journalctl -u systemd-journald --since "1 hour ago" | tail -n 20
Dec 28 08:22:12 server systemd-journald[342]: Suppressed 15432 messages from /system.slice/myapp.service
Dec 28 08:22:42 server systemd-journald[342]: Suppressed 18201 messages from /system.slice/myapp.service

Qué significa: journald ya está descartando logs debido a límites de tasa. Tu problema de disco y tu problema de observabilidad están ocurriendo a la vez.

Decisión: Trata esto como un incidente: reduce el volumen de logs en la fuente. Considera una canalización separada para logs de alto volumen (métricas, trazas o logs muestreados).

Tarea 9: Hacer vacuum de forma segura por tamaño (la forma más rápida de “hacer espacio”)

cr0x@server:~$ sudo journalctl --vacuum-size=2G
Vacuuming done, freed 16.1G of archived journals from /var/log/journal.

Qué significa: Esto aplica inmediatamente un tope sobre los datos almacenados existentes. Elimina archivos archivados antiguos hasta que el uso esté alrededor de 2G.

Decisión: Si el sistema está en llamas, haz esto ahora. Luego implementa la configuración para no repetirlo manualmente.

Tarea 10: Hacer vacuum por tiempo (útil para ventanas de cumplimiento)

cr0x@server:~$ sudo journalctl --vacuum-time=14d
Vacuuming done, freed 6.3G of archived journals from /var/log/journal.

Qué significa: Conserva solo los últimos 14 días (aproximado), eliminando entradas más antiguas.

Decisión: Usa esto cuando tu política de retención sea por tiempo. Combínalo con límites de tamaño para que una tormenta de logs no borre toda tu ventana de 14 días en dos horas.

Tarea 11: Verificar la salud del disco después del vacuum

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   12G   17G  42% /

Qué significa: Has vuelto desde el precipicio. Ahora puedes arreglar la causa raíz sin que el sistema de archivos grite.

Decisión: Configura inmediatamente los límites de journald y corrige la unidad ruidosa. “Lo haremos después” es cómo encuentras el mismo problema la próxima semana.

Tarea 12: Configurar límites (drop-in), y luego reiniciar journald

cr0x@server:~$ sudo install -d -m 0755 /etc/systemd/journald.conf.d
cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/00-limits.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000
EOF
cr0x@server:~$ sudo systemctl restart systemd-journald

Qué significa: Has establecido techos explícitos y un buffer de “mantener libre” para proteger el resto del sistema. También configuraste la cadencia de rotación (MaxFileSec) y límites de tasa.

Decisión: Ajusta estos números según el tamaño de tu disco y las necesidades de respuesta a incidentes. Si tu disco raíz tiene 20–40GB, un journal de 2GB suele ser sensato. En volúmenes dedicados de logs, puedes ir más alto.

Tarea 13: Confirmar los ajustes efectivos tras los cambios

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf | sed -n '1,80p'
# /etc/systemd/journald.conf.d/00-limits.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000

Qué significa: No estás confiando en tu memoria. Estás leyendo la configuración real y la superposición que systemd aplicará.

Decisión: Si ves múltiples drop-ins en conflicto, consólidalos. La proliferación de configuraciones es como los límites dejan de funcionar en silencio.

Tarea 14: Identificar archivos borrados pero aún abiertos (la trampa “df dice lleno, du no”)

cr0x@server:~$ sudo lsof +L1 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
systemd-j 342 root   12w  REG  253,0  1048576     0 1234 /var/log/journal/.../system@000000.journal (deleted)

Qué significa: El espacio puede permanecer “usado” hasta que el proceso cierre el descriptor, incluso si el archivo fue borrado.

Decisión: Reinicia el proceso afectado (a menudo journald mismo) después del vacuum o la limpieza si ves muchos archivos de journal borrados retenidos abiertos.

Tarea 15: Verificar que journald esté sano y no en thrash

cr0x@server:~$ systemctl status systemd-journald --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Sun 2025-12-28 08:40:12 UTC; 2min ago
       Docs: man:systemd-journald.service(8)
           man:journald.conf(5)

Qué significa: journald está en ejecución. Esto no garantiza que no esté descartando mensajes, pero despeja la falla básica de “el servicio está muerto”.

Decisión: Si journald está en crash-loop, podrían estar en juego corrupción de disco o problemas de permisos. Procede a verificar integridad de archivos y permisos.

Tarea 16: Vigilar la tendencia de uso del disco (una alerta temprana económica)

cr0x@server:~$ sudo watch -n 2 'journalctl --disk-usage; df -h / | tail -n 1'
Archived and active journals take up 1.9G in the file system.
 /dev/vda1        30G   12G   17G  42% /

Qué significa: Puedes ver si el uso del journal es estable o sube rápidamente.

Decisión: Si sube rápido incluso después de aplicar límites, estás viendo churn (borrado y reescritura constante) que puede dañar el rendimiento y aún perder logs importantes. Arregla la fuente del logging.

Limitar logs sin arrepentimientos: retención, límites de tasa y separación

Elige una política de retención como eliges backups: basada en recuperación, no en corazonadas

La retención de logs es un requisito de ingeniería con sombrero de cumplimiento. Quieres suficientes logs para responder: “¿Qué cambió?”, “¿Qué falló primero?” y “¿Quién/qué tocó este sistema?”. Si no puedes responder eso, no tienes observabilidad—tienes un feed de ansiedad desplazable.

En una VM Debian típica con disco raíz de 20–50GB, un tope de journal en el rango de 1–4GB es sensato. Si necesitas más, monta un sistema de archivos separado para /var/log o al menos para /var/log/journal. Mantener journals persistentes en tu disco raíz está bien hasta que deja de estarlo—y siempre es “hasta que deja de estarlo”.

Usa límites de tiempo y tamaño

Solo retención basada en tiempo falla durante tormentas de logs: puedes quemar “14 días” en una tarde. Solo retención basada en tamaño falla en periodos tranquilos: podrías conservar 90 días sin querer, lo cual suena bien hasta que alguien pregunta por qué logs de depuración sensibles siguen presentes.

Una combinación pragmática:

• SystemMaxUse= fija un límite superior.
• SystemKeepFree= protege el resto del sistema de archivos del crecimiento del journal.
• MaxRetentionSec= expresa la intención de la política.
• MaxFileSec= controla la granularidad de rotación, lo que puede hacer que las operaciones de vacuum sean menos “todo o nada”.

Los límites de tasa no son sustituto de arreglar servicios ruidosos

Limiter la tasa en journald protege al sistema de un colapso. También oculta evidencia cuando más la necesitas. Si ves mensajes de supresión, trátalos como una señal de fallo.

El patrón correcto es:

1. Reducir el volumen de logs en la fuente (nivel de log, muestreo, arreglar bucles).
2. Limitar el uso de journald para que el nodo siga vivo.
3. Reenviar los logs que realmente necesitas a un sistema central con su propia retención y controles de acceso.

Separa el “buffer local forense” del “retention empresarial”

Los journals locales son geniales para triage inmediato: sobreviven a reinicios, tienen metadatos y están ahí mismo. Pero el disco de un único nodo no es tu archivo de cumplimiento ni tu única fuente de verdad.

Si necesitas retención duradera, reenvía los logs fuera del nodo. Ya uses rsyslog, las opciones de forwarding de journald o un agente, el principio es el mismo: el disco local es el amortiguador, no el almacén a largo plazo.

Sé intencional sobre lo que “importa”

Lo que importa no es “todo”. Lo que importa es:

• Logs de autenticación (intentos de inicio de sesión, sudo, sshd, fallos PAM).
• Cambios de privilegios y reinicios de servicios.
• Errores de kernel y de almacenamiento (timeouts I/O, errores de sistema de archivos).
• Marcas de despliegue y cambios de configuración.
• Errores de aplicación y fallos de solicitudes, pero idealmente no cada migaja de debug.

Cuando limitas logs, estás decidiendo qué puedes permitirte perder. Toma esa decisión conscientemente, no dejando que el disco decida por ti.

Tres mini-historias corporativas (dolor, por triplicado)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana migró una flota de servidores Debian de “syslog clásico más archivos de texto rotados” a un logging centrado en systemd. El equipo SRE apreciaba lo rápido que podían filtrar por unidad y cómo journald capturaba stdout de servicios que antes se perdían.

Alguien hizo una suposición limpia y confiada: “journald tiene valores por defecto sensatos; no llenará el disco.” Nadie verificó qué significaba “sensato” en sus nodos de producción más pequeños. Esos nodos tenían volúmenes raíz modestos porque “solo ejecutan servicios tipo sidecar”.

Un lunes, un servicio empezó a fallar al hablar con una dependencia interna. El bucle de reintentos registró en INFO en cada intento, con volcado completo de payload porque se dejó activada una bandera de debug tras una prueba. El servicio no cayó. Se mantuvo en marcha y gritó.

En pocas horas, los sistemas raíz se llenaron. De repente, servicios no relacionados fallaron: actualizaciones de paquetes, agentes de métricas e incluso SSH en algunas máquinas. El equipo persiguió fantasmas de red porque los primeros síntomas fueron “no podemos desplegar” y “checadores de salud fallando”. Les llevó demasiado tiempo notar el tamaño del journal.

La solución fue aburrida: limitar el journal explícitamente y añadir un buffer de “mantener libre”. La corrección de la causa raíz también fue aburrida: eliminar volcados de payload de los logs por defecto y mover reintentos a métricas estructuradas con muestreo. La lección fue punzante: los valores por defecto no son política, y “no llenará el disco” no es una propiedad—es una configuración.

Mini-historia 2: La optimización que salió mal

Otra organización decidió ser lista. Ejecutaban muchos servicios en una clase de nodo y querían reducir uso de disco e IO. Así que pusieron límites agresivos en journald: SystemMaxUse pequeños, retención corta y límites de tasa bajos. La idea era “proteger el nodo” y “forzar a los equipos a usar la plataforma central”.

Funcionó. El uso de disco se mantuvo bajo. El nodo aguantó las tormentas de logs. Todos se felicitaron y siguieron adelante.

Entonces llegó un incidente de producción: un bug de bajo impacto que ocurría cada pocas horas y dejaba un rastro tenue en los logs. Durante el incidente, el sistema también produjo un estallido de logs ruidosos de una dependencia intermitente. El tope pequeño de journald hizo que los logs relevantes fueran desalojados rápidamente; la limitación de tasa agresiva suprimió los picos; y la canalización central—en mantenimiento—tenía huecos.

Acabaron con el resultado exactamente equivocado: el sistema sobrevivió, pero la evidencia no. El postmortem fue doloroso porque no fue “no registramos”. Fue “registramos, pero diseñamos el sistema para olvidar en el peor momento”.

Volvieron a un buffer local mayor en cada nodo y trataron la canalización central como almacenamiento durable, no como un punto único de fallo. La optimización que salvó disco había incrementado silenciosamente el tiempo medio para diagnóstico.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada con reputación de “lenta” tenía una práctica que los ingenieros se burlaban: cada clase de nodo tenía una política de journald explícita en gestión de configuración. Especificaba límites, retención y un buffer mínimo de espacio libre. Cada cambio era revisado por código. Cada nodo también reenviaba logs críticos fuera del host.

Durante una regresión de driver de un proveedor, el kernel empezó a emitir advertencias de almacenamiento en algunos hosts. Esas advertencias desencadenaron una cascada: un servicio de espacio de usuario comenzó a reintentar y a registrar. El sistema experimentó una tormenta de logs, exactamente el tipo que hace desaparecer discos.

Pero los nodos no se cayeron. journald alcanzó sus límites, mantuvo el buffer de espacio libre intacto y continuó aceptando suficientes mensajes para mostrar la línea temporal. Como los logs se reenviaban, el equipo pudo analizar la secuencia incluso en nodos que se reiniciaron.

El incidente siguió siendo real—los problemas de hardware y drivers siempre lo son. Pero se mantuvo dentro del límite de “rendimiento degradado” en lugar de convertirse en “hosts que no arrancan con evidencia faltante”. La práctica aburrida no gana aplausos. Gana tiempo en servicio.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Disco lleno; /var/log/journal está enorme

Causa raíz: No hay SystemMaxUse / SystemKeepFree explícitos, o los límites son demasiado altos para el tamaño del disco raíz.

Solución: Haz vacuum inmediatamente, luego establece límites explícitos en un drop-in y reinicia journald. Considera un sistema de archivos dedicado para logs.

2) Síntoma: Disco lleno, pero du no muestra dónde se fue el espacio

Causa raíz: Archivos borrados aún mantenidos abiertos (común tras borrados manuales), o crecimiento en otro mount.

Solución: Usa lsof +L1 para encontrar archivos borrados abiertos; reinicia el proceso afectado. Evita borrados manuales; usa journalctl --vacuum-*.

3) Síntoma: Logs faltantes durante el incidente

Causa raíz: La limitación de tasa suprimió mensajes, límites de journal demasiado pequeños causando expulsión rápida, o los logs eran solo volátiles y se perdieron al reiniciar.

Solución: Reduce el volumen de logs en la fuente; ajusta RateLimit*; asegura Storage=persistent y que exista el directorio; reenvía logs críticos fuera del host.

4) Síntoma: Uso de CPU de journald se dispara; el sistema se siente lento durante tormentas

Causa raíz: Alto volumen de logs causa contención e IO; rotaciones demasiado frecuentes; churn constante de vacuum bajo límites estrechos.

Solución: Arregla la unidad ruidosa, incrementa límites modestamente para reducir churn y mantén la rotación razonable (MaxFileSec). Considera mover journals a almacenamiento más rápido o a un volumen separado.

5) Síntoma: Después del reinicio, el historial del journal desapareció

Causa raíz: journald está en modo runtime (/run) porque /var/log/journal no existe o el storage está en auto sin directorio persistente.

Solución: Crea /var/log/journal, configura Storage=persistent, reinicia journald.

6) Síntoma: Limitaste journald, pero el disco sigue llenándose

Causa raíz: Otra canalización de logs está escribiendo en otro lugar (archivos de rsyslog, logs de aplicaciones), o los límites del journal no se aplican debido a capas de configuración.

Solución: Revisa systemd-analyze cat-config para journald, verifica destinos de rsyslog y usa du -x para identificar otros crecimientos bajo /var.

Broma #2: Si alguna vez quieres sentirte poderoso, configura bien SystemKeepFree y mira a tu yo del futuro dejar de mandar mensajes enfadados a tu yo del pasado.

Listas de verificación / plan paso a paso

Cuando el disco ya está lleno (modo incidente)

1. Ejecuta df -hT y confirma qué montaje está lleno.
2. Mide /var/log/journal y confirma con journalctl --disk-usage.
3. Identifica los mayores emisores en los últimos 5–15 minutos (journalctl --since ... pipeline).
4. Haz vacuum por tamaño para restaurar espacio disponible (journalctl --vacuum-size=...).
5. Reinicia journald si sospechas archivos borrados pero aún abiertos.
6. Reduce el volumen de logs en la fuente: nivel de log, revertir, o desactivar flags debug.
7. Establece límites explícitos y buffer de espacio libre usando un drop-in; reinicia journald.

Plan de hardening para los próximos 90 días (aburrido, correcto, efectivo)

1. Definir política: Define la intención de retención (p. ej., 30 días en host, 180 días centralizados para streams críticos).
2. Ajustar almacenamiento: Decide si /var/log/journal pertenece en la raíz. Si no, crea un volumen dedicado o al menos un mount separado para /var.
3. Implementar límites: Usa SystemMaxUse + SystemKeepFree, y un tope temporal (MaxRetentionSec).
4. Hacer visibles las tormentas: Monitoriza mensajes de supresión de journald y aumentos rápidos de journalctl --disk-usage.
5. Mejorar higiene de logs: Aplica guías de logging: no volcados de payload en INFO, no logging en bucles sin backoff, muestrea errores repetitivos.
6. Reenviar lo que importa: Asegura que logs de autenticación, privilegios, kernel y despliegues se copien fuera del host.
7. Probarlo: En staging, simula una tormenta de logs y verifica que no pierdas la evidencia clave del “primer fallo”.

Guía de configuración: números que suelen funcionar

• Discos raíz pequeños (20–40GB): SystemMaxUse=1G–3G, SystemKeepFree=1G, MaxRetentionSec=2week–1month.
• Volumen dedicado de logs (100GB+): SystemMaxUse=10G–50G, SystemKeepFree=5G–20G, además de forwarding central.
• Nodos de alto churn: Prefiere arreglar emisores ruidosos antes que subir límites; el churn puede convertirse en problema de rendimiento y desgaste en SSDs.

Preguntas frecuentes

1) ¿Es journald “malo” comparado con rsyslog?

No. journald es excelente para logging local y estructurado con contexto de unidad. rsyslog es excelente para logs de texto y forwarding flexible. En producción suelen ser complementarios: journald localmente, forwarding centralmente.

2) Si configuro SystemMaxUse, ¿journald dejará de registrar cuando alcance el límite?

Seguirá operando rotando y eliminando entradas antiguas para mantenerse dentro de los límites. Eso significa que el sistema sobrevive, pero evidencia antigua se pierde. Por eso deberías reenviar logs críticos fuera del host.

3) ¿Cuál es la diferencia entre SystemMaxUse y SystemKeepFree?

SystemMaxUse limita la huella máxima del journal. SystemKeepFree obliga a mantener un espacio libre mínimo en el sistema de archivos. Si te importa la estabilidad del nodo, SystemKeepFree es la protección que evita que “los logs maten al SO”.

4) ¿Debería eliminar archivos bajo /var/log/journal manualmente?

Evítalo. Usa journalctl --vacuum-size o --vacuum-time. El borrado manual aumenta la probabilidad de archivos borrados pero abiertos, estado inconsistente y que te saltes la decisión de política por completo.

5) ¿Por qué veo “Suppressed N messages” y debo entrar en pánico?

Debes prestarle atención. Significa que estás perdiendo líneas de log. A veces es aceptable durante una tormenta, pero a menudo es síntoma de un servicio roto o de un nivel de log mal configurado. Arregla la fuente.

6) Necesito logs para auditorías. ¿Puedo aun así limitar journald?

Sí, y deberías. Trata el journal en el host como un buffer limitado y reenvía los logs relevantes para auditoría a un almacenamiento inmutable o con controles de acceso. Auditabilidad y “retención local infinita” no son lo mismo.

7) ¿Y los contenedores—esto se pone peor?

Con frecuencia, sí. Los contenedores tienden a loguear por stdout, y si ejecutas muchos contenedores habladores en un host, journald se convierte en el sumidero de todo eso. Tus límites deben reflejarlo y la plataforma debe imponer niveles de log y muestreo.

8) ¿Cómo sé si mis límites son demasiado pequeños?

Dos señales: (1) no puedes reconstruir líneas temporales porque los mensajes relevantes se expulsan rápido, y (2) journald está constantemente haciendo vacuum/rotando bajo carga (churn). Incrementa límites modestamente y reduce logging ruidoso en la fuente.

9) ¿Mover /var/log/journal a un filesystem separado realmente ayuda?

Sí. Aísla dominios de fallo. Si los logs llenan el volumen de logs, normalmente no impedirán que el SO escriba estado crítico en la raíz. Aún necesitas límites, pero el radio de daño se reduce.

10) ¿Cuál es la limpieza de emergencia más segura si no tengo tiempo?

journalctl --vacuum-size=..., luego reinicia journald si es necesario, y luego arregla la unidad ruidosa. No empieces a borrar archivos aleatorios bajo /var cuando estés cansado.

Conclusión: próximos pasos que puedes hacer hoy

Cuando journald se come tu disco, rara vez es porque journald está “fuera de control”. Es porque no le diste límites, y porque algún servicio decidió que la mejor manera de expresar su angustia era imprimir una novela cada milisegundo.

Haz esto a continuación:

1. Establece límites explícitos con SystemMaxUse y SystemKeepFree usando un drop-in, no la memoria tribal.
2. Combina retención por tiempo y tamaño para que las tormentas no borren tu ventana de investigación.
3. Encuentra y arregla a los mayores emisores—logs de debug en producción son un impuesto que pagas con disco y sueño.
4. Reenvía lo que importa fuera del host para que el nodo pueda morir sin llevarse la evidencia.
5. Monitorea mensajes de supresión; son tu aviso temprano de que la observabilidad está fallando.

Si recuerdas una cosa: limitar logs no se trata de borrar historial. Se trata de elegir qué historial puedes permitirte conservar—a propósito.