Retención de logs y presupuesto de disco en un host: journald, logrotate y tamaño del registro de eventos de Windows

Qué es

Todo almacén de logs en un host tiene un límite de tamaño, que se configura de forma distinta según el mecanismo. journald.conf(5) documenta SystemMaxUse= como el parámetro que limita el espacio total en disco que puede ocupar el journal persistente en /var/log/journal (por defecto, el 10 % del sistema de archivos con un tope de 4G; los límites persistentes solo se aplican si existe /var/log/journal). Junto a él hay otros parámetros relacionados: SystemKeepFree= (por defecto 15 %, con el mismo tope), SystemMaxFileSize= y los de tiempo MaxRetentionSec=/MaxFileSec=, que controlan la rotación y la antigüedad con independencia del tamaño. logrotate.conf(5) documenta maxage, que elimina los archivos de log rotados con más de cierto número de días, sin importar el valor de rotate también configurado; por tanto, pueden aplicarse a la vez un límite por cantidad y otro por antigüedad, y esta solo se comprueba cuando se rota el log. En Windows, wevtutil sl <channel> /ms:<bytes> establece el tamaño máximo de un registro de eventos en bytes, según la documentación de wevtutil; al alcanzarlo, el registro sobrescribe los eventos más antiguos o exige borrarlo o archivarlo manualmente, según el comportamiento de retención configurado para ese canal.

Por qué importa

Un almacén de logs que se llena sin avisar deja de aceptar entradas nuevas o empieza a sobrescribir las antiguas; en ambos casos se pierde justo la evidencia que hace falta durante un incidente. Dimensionar estos límites es una decisión de planificación de capacidad: si son demasiado pequeños, la evidencia desaparece antes de que alguien la lea; si son demasiado grandes, los logs compiten con las aplicaciones por el espacio en disco, un problema que el artículo sobre salud del disco de esta serie aborda desde el lado del almacenamiento.

La retención como cuestión normativa o legal (cuánto tiempo deben conservarse determinados tipos de registro y con qué controles de acceso) es una decisión que corresponde a la política de la propia organización y, cuando proceda, a su asesoría jurídica. Este artículo trata únicamente los ajustes mecánicos de presupuesto de disco, no lo que exija ninguna normativa.

Cómo aplicarlo

• Define SystemMaxUse= en /etc/systemd/journald.conf (o en un drop-in) con un valor fijo adecuado a la partición, por ejemplo SystemMaxUse=2G; aplícalo con systemctl restart systemd-journald y comprueba el uso actual con journalctl --disk-usage. journalctl --vacuum-size=2G recorta de inmediato los archivos ya archivados.
• Para los archivos escritos por rsyslog o por aplicaciones y rotados con logrotate, combina rotate <N> (conservar N ciclos) con maxage <days> en el archivo correspondiente de /etc/logrotate.d/, de modo que los archivos se eliminen según el primer límite que se alcance.
• Para los canales de Windows, ya sean reenviados o conservados localmente, consulta el tamaño actual y fija un nuevo límite de forma no interactiva: wevtutil gl Security muestra el maxSize actual; wevtutil sl Security /ms:1073741824 (desde un símbolo del sistema con privilegios elevados) lo fija en 1 GiB. Según la documentación, los tamaños se redondean a múltiplos de 64 KB, con un mínimo de 1 MB.
• Reenvía a un colector remoto todo lo que deba sobrevivir a la reconstrucción de un host (consulta los artículos de esta serie sobre el reenvío con rsyslog y journald), en lugar de depender únicamente de la retención local.

Trampas

• Suponer que un SystemMaxUse= grande implica que los logs se conservan para siempre; MaxRetentionSec= y la presión sobre el disco pueden eliminar entradas antes.
• Configurar el modo de un registro de Windows como "overwrite as needed" (sobrescribir según sea necesario) sin reenviarlo además, con lo que se pierden los eventos antiguos sin ningún aviso en cuanto se alcanza el límite de tamaño.
• Dar por hecho que cualquiera de estos ajustes cumple un requisito de retención sin comprobar qué especifica realmente ese requisito.