Rotar los archivos de trazas con log4j por fecha o tamaño

Una tendencia en el uso de aplicaciones basadas en contenedores o microservicios es que estos sus mensajes de trazas o logs los emitan a la salida estándar del proceso, esto tiene la ventaja de que la aplicación no ha de conocer ni impone ninguna limitación si posteriormente se utiliza alguna herramienta para agregar esos logs. Una combinación es utilizar ELK (Elasticsearch para indexar el texto, Logstash para guardar los logs, Kibana como interfaz de consulta) pero en un futuro podría cambiarse por otra y la aplicación que emita sus logs en la salida estándar no requeriría ninguna modificación.

Otra posibilidad adicional o como sustituta es guardar los log en un archivo en el sistema de archivos. Sin embargo, hay que estimar la cantidad de información que puede llegar emitir la aplicación para aprovisionar en la máquina espacio suficiente para darles cabida. Para limitar el espacio que pueden llegar a ocupar los logs se pueden rotar los archivos cuando lleguen a cierto tamaño o por fecha. De no imponer un cierto límite a los archivos de log estos pueden llegar a consumir todo el espacio de almacenamiento disponible y ocasionar una caída del servicio de la aplicación.

En la librería log4j para realizar logging en Java la política y estrategia de rotación se define con el Appender de tipo RollingFileAppender. Las políticas de rotado definen cuando se realiza el rotado, por fecha, por tamaño o al inicio de la aplicación. La estrategia define cómo se realiza el rotado y que nombre se le da a los archivos rotados, cuantos rotados de archivos se conservan y si los archivos rotados se archivan comprimidos.

En la configuración de RollingFileAppender los parámetros de configuración fileName y filePattern indican en que archivo se generan los logs y que nombre se les da a los archivos rotados y si se comprimen. La política CronTriggeringPolicy permite definir con una expresión cron en que momento y fecha periódica se realiza el rotado, la política SizeBasedTriggeringPolicy rota los archivos cuando lleguen a cierto tamaño especificado por parámetro de configuración en KB, MB o GB. Con la estrategia DefaultRolloverStrategy por defecto se configura cuantos archivos de log se quieren conservar como máximo, una vez llegado al límite el más antiguo se elimina limitando de esta forma el espacio ocupado por los logs de la aplicación.

En el siguiente ejemplo se muestra el archivo de configuración de log4j que emite las trazas a la consola y a un archivo en los que cada día o cuando lleguen a 500 MB son rotados. Al especificar en el parámetro filePattern la extensión gz los archivos rotados se comprimen para que ocupen menos espacio. Como se define en DefaultRolloverStrategy se conservan como máximo 10 archivos rotados, por tanto ocupando un máximo de 5 GiB.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

configuration:
  status: warn

  appenders:
    console:
      name: STDOUT
      patternLayout:
        Pattern: "%d{DEFAULT} %X{uuid} %-5level %60.60logger %msg%n"

    rollingFile:
      name: RollingFile
      fileName: "logs/app.log"
      filePattern: "logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz"
      patternLayout:
        pattern: "%d{DEFAULT} %X{uuid} %-5level %60.60logger %msg%n"
      policies:
        cronTriggeringPolicy:
          schedule: "0 0 * * * ?"
        sizeBasedTriggeringPolicy:
          size: "500 MB"
      defaultRollOverStrategy:
        max: "10"

  loggers:
    root:
      level: info
      appenderRef:
        ref: STDOUT
      appenderRef:
        ref: RollingFile

Rotar los logs es una buena idea ya que en algunas aplicaciones Java si la aplicación por alguna circunstancia emite a los archivos de log un stacktrace de forma continuada generando una considerable cantidad de información en poco tiempo, si se guarda en el almacenamiento acaba por consumir todo el espacio disponible por muy previsor que se haya sido al aprovisionar el tamaño del espacio de almacenamiento, la aplicación terminará por dejar de prestar su servicio y alguien un sábado a las 3:00 de la noche es posible que deba levantarse de la cama porque ha llegado alguna alerta de monitorización si se es afortunado de disponer de uno para reaccionar cuanto antes y antes de que la aplicación deje de funcionar o peor recibe una llamada de teléfono cuando la aplicación ya se ha dejado de funcionar.