La Red de Conocimientos Pedagógicos - Currículum vitae - RollingFileAppender del appender Log4j

RollingFileAppender del appender Log4j

Este artículo está traducido del documento oficial de log4j (algunos detalles son de comprensión personal): https://logging.apache.org/log4j/2.x/manual/appenders.html # agregador de archivos rodantes.

RollingFileAppender es un OutputStreamAppender, que escribe registros en un archivo llamado nombre de archivo del elemento de configuración y también revierte el archivo de registro según TriggeringPolicy y RolloverPolicy. Se basa en RollingFileManager (heredado de OutputStreamManager) para realizar la lectura y escritura de archivos (E/S) y la reversión. Aunque los RollingFileAppenders inicializados con diferentes configuraciones no se pueden * * * disfrutar, los RollingFileManagers sí se pueden * * * disfrutar. Por ejemplo, aunque dos aplicaciones web en el mismo contenedor de servlets tienen sus propias configuraciones, log4j puede escribir en el mismo archivo de registro al mismo tiempo si se carga a través de un cargador de clases común.

RollingFileAppender depende de la política de activación y RolloverStrategy. La política de activación determina si se realiza la reversión y RolloverStrategy determina cómo realizar la reversión. Si RolloverStrategy no está configurado, se utilizará DefaultRolloverStrategy. A partir de la versión log4j, las operaciones de eliminación personalizadas se pueden configurar en DefaultRolloverStrategy para completar la operación de eliminación personalizada durante la reversión. A partir de la versión log4j, si el nombre del archivo no está configurado, se utilizará DirectWriteRolloverStrategy de forma predeterminada en lugar de DefaultRolloverStrategy. A partir de la versión log4j, puede configurar operaciones de visualización de atributos de archivos POSIX personalizadas en DefaultRolloverStrategy. Si no está definido, se utilizará el archivo POSIX heredado de RollingFileAppender.

RollingFileAppender no admite el bloqueo de archivos de registro.

CompositeTriggeringPolicy se utiliza para combinar múltiples políticas de activación. Si uno de ellos devuelve verdadero, CompositeTriggeringPolicy devuelve verdadero.

El siguiente fragmento xml combina tres estrategias de activación: 1. Cuando se inicia la JVM; 2. Cuando el archivo de registro alcanza los 20 MB; 3. Cuando la fecha actual no coincide con la fecha de inicio del archivo de registro (por archivo de talento);

Revertir según la expresión cron. Esta estrategia está controlada por un temporizador y los eventos de registro se procesan de forma asincrónica, por lo que es posible que aparezcan registros del período anterior o siguiente al principio o al final del siguiente archivo de registro. El elemento de configuración filePattern debe contener una marca de tiempo; de lo contrario, el archivo de destino se sobrescribirá cada vez que se revierta.

Si el tiempo de creación del archivo es menor que el tiempo de inicio de la JVM y el tamaño del archivo de registro es aproximadamente igual al tamaño mínimo del archivo, se activará una reversión cuando se inicie la JVM.

Nota: Google App Engine

Cuando la aplicación se ejecuta en Google App Engine, esta estrategia solo puede utilizar el tiempo inicial de Log4J como base para el juicio. (Google App Engine restringe el acceso a clases específicas, por lo que Log4J no puede obtener la hora de inicio de la JVM a través del método Java . lang . Management . Management Factory . getruntimemxbean(). getstarttime(), y solo puede cambiar a la hora inicial de Log4J.

)

SizeBasedTriggeringPolicy activará una reversión cuando el tamaño del archivo alcance el valor especificado. El tamaño se puede especificar en diferentes unidades, incluidas: bytes predeterminados, KB con sufijo KB, MB o GB; por ejemplo, 2048 significa 2048 bytes y 20 MB significa 20 megabits. Cuando se utiliza junto con una política de tipo de tiempo, el parámetro filePattern debe contener %i; de lo contrario, el archivo se sobrescribirá porque las políticas de activación basadas en tamaño no cambian el parámetro de tiempo en el nombre del archivo. Cuando se utiliza sin una política de reversión de tipo de tiempo, la política de activación basada en el tamaño cambia el parámetro de tiempo en el nombre del archivo.

TimeBasedTriggeringPolicy activará una reversión cuando la regla de hora actual (fecha/hora) ya no sea consistente con la fecha/hora en el nombre del archivo actual. La política acepta el atributo de intervalo, que se utiliza para especificar la frecuencia de reversión en función del tiempo y la modulación.

La política de reversión predeterminada admite reglas de fecha/hora configuradas en la propiedad RollingFileAppender filePattern y contadores numéricos. La regla de fecha/hora en el modo de archivo se establece en la hora actual y el contador se incrementa en cada reversión. Si incluye una fecha/hora y un contador, el contador se reiniciará cuando cambie el valor de la regla de fecha/hora. Si el patrón del archivo termina con ",". gz",". zip", ".bz2", "deflate", ".pack200" o ".xz", los archivos revertidos se comprimirán en el formato correspondiente. Para usar bzip2, Deflate, Pack200 y XZ, debe introducir la biblioteca de compresión Apache Commons, y XZ también debe introducir XZ para Java. El patrón también puede contener referencias de búsqueda que se pueden resolver en tiempo de ejecución, como se muestra en el siguiente ejemplo.

La política de reversión predeterminada admite tres tipos de contadores. Para ilustrar claramente cómo funciona, supongamos que el valor mínimo del contador es 1, el valor máximo es 3, el nombre del archivo es foo-%i.log y el modo del archivo es foo-%i.log..

Para comparar el efecto cuando el elemento de configuración fileIndex se establece en "min", según las suposiciones de la tabla anterior, ocurrirá el siguiente fenómeno.

Finalmente, en la versión 2.8, si fileIndex se establece en "nomax", los elementos de configuración max y min se ignorarán. Entonces, cada vez que retrocede, el contador se incrementa y no hay límite en la cantidad máxima de archivos para retroceder.

DirectWriteRolloverStrategy generará el registro directamente en el archivo especificado por filePattern. Esta regla no cambiará el nombre del archivo cuando se revierta. Si la política basada en el tamaño genera múltiples reversiones durante un tiempo en el que la política de reversión no está vigente, se agrega automáticamente un contador al nombre del archivo de reversión (pero el tiempo en el archivo permanece sin cambios) y continúa creciendo hasta que la política basada en el tiempo. La política de retroceso está en vigor. Una nueva ronda de contracrecimiento comenzará de nuevo.

Nota: Si se especifican reglas que requieren compresión (como el sufijo zip) en filePattern, el archivo escrito actualmente no se comprimirá a menos que se cierre el programa. Además, si retrocede según las reglas de tiempo, los archivos recién escritos no se comprimirán.

Los siguientes son ejemplos del uso de estrategias activadas por tiempo y por tamaño. Creará hasta 7 archivos de reversión cada día y los archivos de reversión se guardarán en un directorio llamado año y mes. Cada archivo de reversión se comprimirá en formato gzip:

En el segundo caso, especifique el número máximo de archivos de reversión; cuando sean más de 20, se eliminarán:

El siguiente ejemplo También es un ejemplo del uso de una estrategia activada por tiempo y una estrategia activada por tamaño. Asimismo, sólo se conservan un máximo de 7 archivos de reversión por día. El archivo de reversión se colocará en un directorio con el nombre del año y mes actuales y también se comprimirá con gzip. En particular, esta vez requerimos que los archivos se reviertan cada 6 horas, y la reversión debe ocurrir dentro de una hora divisible por 6.

El siguiente ejemplo utiliza las estrategias de activación cron y tamaño y no tiene límite en la cantidad de archivos de reversión.

La política de Cron activará una reversión a las 0:00 cada hora, y la política de reversión de tamaño activará una reversión cuando el archivo sea igual a 250 MB:

El siguiente ejemplo es similar al anterior, excepto que el número de archivos revertidos por hora El límite es 10:

Log4j-2.5 introduce la acción de eliminación, que compensa la estrategia de DefaultRolloverStrategy de eliminar solo archivos según el máximo, brindando a los usuarios más formas de eliminar archivos durante la reversión. Las operaciones de eliminación permiten a los usuarios configurar una o más condiciones para seleccionar archivos para su eliminación.

Cabe señalar que la acción de eliminación puede eliminar cualquier archivo que cumpla con los requisitos, no solo revertir archivos, así que tenga cuidado al utilizar esta función. Si elimina accidentalmente los archivos incorrectos, puede usar el parámetro testMode para probar su configuración.

El siguiente ejemplo utiliza una estrategia de activación cron para activar una reversión a medianoche todos los días. Los archivos de reversión se almacenan en el directorio para el año y mes actuales. Al revertir, se eliminarán todos los archivos en el directorio de ruta base que coincidan con la expresión "/app-.log.gz" y cuya última modificación haya sido mayor o igual a 60 días.

El siguiente ejemplo utiliza una estrategia de activación de tiempo y tamaño. Esta política guardará hasta 100 archivos de reversión por día en el directorio para el mes y año actuales. Cada archivo de reversión se comprime con gzip y se revierte cada hora. Durante cada reversión, las condiciones para eliminar archivos son: el nombre del archivo satisface la expresión "/app-.log.gz" y el tiempo de la última modificación es 30 días o más, pero el último archivo de 100 GB no se eliminará (el tamaño total es mayor que 100 GB) o los últimos 10 archivos (el número de archivos es mayor que 10).

En el siguiente ejemplo, utilizando la estrategia de activación cron, la reversión se activará a la medianoche todos los días. Los archivos de reversión se almacenan en directorios que llevan el nombre del año y mes actuales. Este script devuelve una lista de archivos de reversión con fecha 13 (viernes) en el directorio de ruta base. La operación de eliminación eliminará todos los archivos devueltos por el script.

Log4j-2.9 introduce la acción PosixViewAttribute, que brinda a los usuarios más permisos de propietario y grupo para controlar los archivos de reversión. Esta acción alienta al usuario a configurar uno o más criterios para seleccionar archivos dentro de una ruta base calificada.

La siguiente es una configuración de ejemplo que utiliza RollingFileAppender, que define diferentes vistas de atributos de archivos POSIX para el archivo de registro actual y el archivo de registro continuo.