Log4j vs Logback: escritura concurrente en el mismo registro?

Question

Tengo varias aplicaciones web ejecutándose en el mismo tomcat.

Tengo dos preguntas:

1- Mediante la búsqueda, que entiende que cuando múltiples aplicaciones están presentes, iniciar sesión en el mismo fichero puede hacer que algunos problemas. ¿Es ese el caso para múltiples aplicaciones que se ejecutan en el mismo servidor web? ¿Eso también es correcto cuando se utiliza salida stdout predeterminada?

2- En la biblioteca Logback hay un modo prudente:

En el modo prudente, FileAppender escribirá con seguridad en el archivo especificado, incluso en presencia de otros casos FileAppender que se ejecutan en diferentes máquinas virtuales de Java, lo que potencialmente se ejecutan en diferentes hosts. El valor predeterminado para el modo prudente es falso.

Quiero saber si el uso de Logback solo es favorable en varias JVM o también es ventajoso para múltiples aplicaciones que se ejecutan en el mismo servidor web. Si no, ¿es idéntico a log4j en este aspecto?

Gracias

Answer 1

1. Sí. En general, su principio debería ser que escriba un archivo de registro diferente para cada aplicación (web o no). La alternativa es dejar que el servidor decida en qué archivo escribir. JBoss tiene formas de cerrar la sesión genéricamente, que irá al mismo archivo. Sin embargo, aún prefiero tener un registro separado para cada aplicación.
2. Hasta donde yo sé, log4j y Logback apuntan a ser mínimos en la sobrecarga que pueden causar a la aplicación, por lo que es poco probable que haya uno que sea más favorable. Si múltiples JVM son esenciales para usted, creo que Logback es mejor para manejarlo, pero usarlo fuera de esto no es una mala idea.

Answer 2

Hay una cosa que debe ser aclarado: No habrá problemas cuando instancias diferentes de Log4J son escribir en el mismo archivo al mismo tiempo, tanto si tiene instalado en la misma máquina virtual Java o no.

Al usar servidores (y diferentes cargadores de clases) es posible tener una única instancia en todo el servidor o varias instancias de Log4j, dependiendo de la implementación y la configuración.

1. Ver arriba. Stdout puede sufrir el mismo problema de salida mixta, pero no al rotar archivos.
2. El modo prudente de Logback abordaría la escritura concurrente por diferentes instancias (la misma JVM o no). Si su configuración utiliza una instancia de Log4j en todo el servidor, no hay ventajas para este aspecto.

Answer 3

En tanto log4j y logback si varios casos FileAppender escribir en el mismo archivo de registro, existe un alto riesgopara dicho archivo de registro de convertirse en corrupto. Si las instancias FileAppender se ejecutan en la misma JVM o JVM diferentes es irrelevante, es decir, el riesgo de corrupción es el mismo.

Como se menciona en los documentos, en FileAppender corrupción evitará prudent mode de logback, incluso en la presencia de otros FileAppender instancias que se ejecutan en el mismo o diferentes JVM, potencialmente se ejecutan en diferentes hosts. Por defecto, el modo prudente está deshabilitado.

La consola no se puede dañar, por lo que la pregunta es discutible.

Answer 4

El uso de Filelocks nunca es realmente eficiente/seguro, por lo que al iniciar sesión en el mismo archivo desde diferentes apéndices/trabajos de JVM, no es recomendable. Ver la configuración que tomé directamente desde logback-appenders-faq.

<configuration> 
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <!-- Support multiple-JVM writing to the same log file --> 
    <prudent>true</prudent> 
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
     <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern> 
     <maxHistory>30</maxHistory> 
    </rollingPolicy> 

    <encoder> 
     <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern> 
    </encoder> 
    </appender> 

    <root level="DEBUG"> 
    <appender-ref ref="FILE" /> 
    </root> 
</configuration> 

Sus otras opciones para varias JVM escritura a alguna fuente unificada son SocketAppenders y la JDBCAppender.

El JDBCAppender será reemplazado por completo en el futuro y aunque es no se recomienda tampoco. Ver logbacks mailinglist.

SocketAppenders puede ser un poco crudo, ya que probablemente no estaba planeando escribir mucho código para logback.

Hay una opción más. Puede usar algo como clusterlog, que ha sido desarrollado para resolver exactamente el tipo de problema que tiene.