Los registros: lo único que crece sin que nadie lo haya decidido

La mayor parte de lo que llena tu disco lo añadiste tú: máquinas virtuales, copias, imágenes de instalación. Cada una fue una decisión.

Los registros son distintos. Crecen porque el sistema está funcionando. Nadie dijo nunca "que este archivo se haga más grande".

El crecimiento es lento pero sin límite

Un archivo de registro puede crecer unos pocos kilobytes al día. Eso no llama la atención durante meses. Un año después sigue siendo pequeño.

Pero no tiene techo. Y un crecimiento sin techo, por lento que sea, se convierte en un problema si esperas lo suficiente.

El multiplicador que nadie espera: la avería acelera la escritura

Aquí está el verdadero asunto del artículo.

Un sistema sano escribe poco. Si una comprobación da error en cada ejecución, en cada ejecución cae una línea en el mismo archivo. Para un trabajo que corre cada quince minutos eso son noventa y seis líneas al día, y no se detiene.

Así que el registro crece más rápido justo cuando menos puedes mirarlo: mientras una avería está en curso.

Y su peor versión

Aparece un problema, los registros se aceleran, el disco se llena. El disco lleno provoca problemas nuevos. Los problemas nuevos producen más registros.

A partir de ahí se vuelve más difícil encontrar la avería original, porque la mayoría de los errores en pantalla no son consecuencia del primer problema sino del disco lleno.

La regla: todo lo que escribe debe tener un techo

"Ya lo limpiaremos" no es un plan. Hace falta un límite mecánico que funcione sin que nadie tenga que acordarse.

Esta regla no vale solo para los registros del sistema: vale para todo archivo producido por los servicios que ejecutas, por los trabajos programados y por los recolectores.

Dos errores frecuentes al montar la rotación

Uno: la regla que se rompe por un archivo inexistente. Algunos archivos solo aparecen cuando se usa la función correspondiente. La regla hay que escribirla de modo que no dé error cuando falta un archivo; si no, una función que nunca usas detiene toda la rotación.

Dos: el método de rotación equivocado. Renombrar el archivo y mandar al servicio que escribe una señal de "vuelve a abrir" es el método habitual, pero solo funciona si existe un servicio de larga vida. Si quien escribe es un trabajo breve que abre y cierra cada vez, no hay a quién mandar la señal; en ese caso el método correcto es copiar el contenido y vaciar el archivo en su sitio.

Ambos son fallos silenciosos: la regla está puesta, el archivo sigue creciendo, y nadie nota que la regla no funciona.

Y la pregunta de la máquina ya instalada

Si escribes una regla de rotación solo en el script de instalación, nunca llega a las máquinas instaladas antes de que la regla existiera. Esas máquinas funcionan años sin ella.

Lo correcto es escribir la regla en cada arranque: así las instalaciones más antiguas la reciben al pasar a una versión nueva.

Qué hace Atlas

Todo este artículo salió de una medición que Atlas hizo sobre sí mismo, así que hay que contarlo con honestidad.

Atlas corre con permisos de root en la máquina del cliente y escribe en varios archivos de registro: el resumen del vigilante cada quince minutos, la salida de las actualizaciones planificadas en cada ejecución, su propio registro de autoactualización. Se midió y ninguno de ellos se estaba rotando, porque la instalación no escribía una regla de rotación en ninguna parte. En una máquina en servicio, el registro del vigilante había llegado a ciento ochenta kilobytes en treinta y dos días y no había mecanismo para reducirlo.

El número parece pequeño y aquel día no era un problema. El problema era que el crecimiento no tenía límite, más la aceleración descrita arriba. Los registros de actualizaciones planificadas capturan toda la salida del gestor de paquetes en cada ejecución, lo que puede llegar a megabytes por ejecución.

Ahora la regla se escribe, y las dos trampas de arriba se tratan a propósito: los archivos ausentes se toleran, y la rotación usa el método copiar y luego vaciar, porque quienes escriben son procesos breves lanzados por un trabajo programado.

Y la regla se escribe en el arranque, no en el script de instalación. El motivo es justo la pregunta de arriba: que las máquinas instaladas antes también reciban la regla al pasar a una versión nueva.