Cómo solucionar un diario de systemd lleno

El diario de systemd almacena todos los mensajes de registro que genera tu servidor y, en un VPS con una partición raíz pequeña, puede consumir silenciosamente todo tu espacio de disco disponible. Cuando eso ocurre, los servicios no se inician, las escrituras se bloquean y pierdes precisamente los datos de diagnóstico que necesitas para averiguar qué ha fallado. Esta guía explica cómo diagnosticar el problema, liberar espacio de inmediato y configurar journald para que no vuelva a ocurrir.

Diagnóstico del problema

Empiece por comprobar cuánto espacio está utilizando el diario:

journalctl --disk-usage

Esto indica el tamaño combinado de todos los archivos de registro activos y archivados. Compáralo con el espacio disponible en disco df -h. En una partición raíz de 20 GB, incluso 2 GB de registros representan más del 10 % del disco total, lo cual es suficiente para causar problemas.

A continuación, averigüe qué servicios están generando más ruido. Esta línea de comando clasifica las 10 principales fuentes de registros de las últimas 24 horas:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Filtra específicamente los errores con journalctl -p err -b para ver si un solo servicio está atascado en un bucle de fallos y saturando el diario. También puedes comprobar si journald está limitando la tasa de ningún servicio:

journalctl -u systemd-journald | grep -i "suppressed"

Los mensajes de supresión indican que un servicio ha superado el umbral predeterminado de 10 000 entradas en 30 segundos. Ese es el culpable.

Hay algunas cosas que son especialmente comunes en las instancias VPS. Si Storage=auto está configurado y /var/log/journal/ existe, journald utiliza almacenamiento persistente con un límite predeterminado de aproximadamente 4 GB. En una partición raíz pequeña, eso se llena rápidamente. Los apagados incorrectos también pueden dejar archivos de diario dañados con el .journal~ . Estos archivos no se rotan normalmente y siguen consumiendo espacio.

Borrado seguro de los registros

Antes de eliminar nada, rote el archivo de registro activo para que se conserven los registros actuales:

journalctl --rotate

A continuación, elimine los registros archivados. Puede filtrar por antigüedad, tamaño o número de archivos:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

La primera opción elimina los registros de más de 24 horas. La segunda reduce el tamaño total del diario a 100 MB. La tercera conserva solo los cinco archivos archivados más recientes. Elija la que mejor se adapte a su situación.

Si el disco está completamente lleno y los comandos journalctl no responden, es posible que tenga que eliminar los archivos de registro manualmente:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Esta es la última opción. Borra todos los registros almacenados y vuelve a crear el directorio con los permisos correctos. Tras cualquier limpieza, reinicia el daemon y comprueba:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Configuración de los límites de tamaño de Journald

La configuración predeterminada de journald es generosa. En un VPS, resulta excesiva. Edita la configuración para establecer límites máximos estrictos en el almacenamiento de registros. Crea un archivo de anulación en lugar de editar la configuración principal directamente, para que tus cambios se mantengan tras las actualizaciones de paquetes:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Las directivas clave:

Configuración de ambos SystemMaxUse y SystemKeepFree te ofrece un enfoque de doble seguridad: los registros tienen un límite de tamaño fijo y el sistema siempre dispone de margen de maniobra, independientemente de lo que haya en el disco.

Almacenamiento persistente frente a volátil

La Storage= directiva controla dónde van los registros. Establezca Storage=persistent para escribir los registros en /var/log/journal/ en el disco. Esto es lo que se recomienda para servidores de producción, ya que los registros sobreviven a los reinicios y permite investigar los fallos a posteriori. Si el directorio no existe, créalo:

sudo mkdir -p /var/log/journal

La alternativa, Storage=volatile, es mantener los registros en la RAM en /run/log/journal/. Los registros desaparecen al reiniciar. Esto tiene sentido para contenedores efímeros o servidores que reenvían todos los registros a un sistema externo.

Desactivación de la compresión en servidores de alto tráfico

Journald comprime de forma predeterminada los objetos de datos de más de 512 bytes. En servidores que gestionan un gran volumen de registros, esto añade una carga adicional a la CPU. Establece Compress=no si reenvías los registros externamente y no necesitas minimizar el almacenamiento local. Configúralo también ForwardToConsole=no en producción. El reenvío de la consola es síncrono, y una consola serie virtual bloqueada puede bloquear por completo el demonio journald.

Después de cualquier cambio de configuración, reinicie el servicio:

sudo systemctl restart systemd-journald

Automatización del mantenimiento de registros

La limpieza manual no es escalable. Crea un temporizador de systemd para limpiar los registros de forma programada. Configura una unidad de servicio en /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

A continuación, cree un temporizador correspondiente en /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Actívelo con sudo systemctl enable --now journal-vacuum.timer. El temporizador se ejecuta todos los domingos a las 2 de la madrugada y aplica la retención basada tanto en el tiempo como en el tamaño en una sola pasada.

Hay algo que el temporizador no detectará: los archivos de diario dañados. Tras un apagado incorrecto, journald pone en cuarentena los archivos dañados añadiendo un ~ al nombre del archivo. Estos .journal~ archivos siguen contando para el uso del disco, pero no se limpiarán automáticamente. Comprueba y elimina periódicamente los antiguos:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Reenvío de registros a un sistema externo

Para servidores en los que se necesita una retención a largo plazo sin aumentar el almacenamiento local, reenvíe los registros a un sistema centralizado. El método más sencillo es habilitar el reenvío de syslog en journald.conf:

ForwardToSyslog=yes

Para registros estructurados con metadatos completos (PID, UID, nombres de unidades), utilice systemd-journal-remote para enviar entradas en formato JSON a una plataforma de gestión de registros. El almacenamiento externo de registros también protege su pista de auditoría si el disco local falla o el servidor se ve comprometido.

Conclusión

Un diario de systemd lleno es fácil de solucionar y de prevenir. Los pasos clave:

• Comprueba el uso con journalctl --disk-usage e identifica los servicios que generan ruido.
• Libera espacio inmediatamente con journalctl --rotate seguido de --vacuum-size o --vacuum-time.
• Establezca límites de tamaño explícitos en un archivo de anulación de journald.conf.
• Automatice la limpieza con un temporizador de systemd.
• Reenvíe los registros externamente para su conservación a largo plazo.

Los planes de servidores VPS y dedicados de FDC proporcionan la E/S de disco y el almacenamiento necesarios para las cargas de trabajo de registros de producción.