2012-08-12 12 views
15

Ho diverse applicazioni Web in esecuzione sullo stesso tomcat.Log4j vs Logback: scrittura simultanea sullo stesso registro?

Ho due domande:

1- Con la ricerca, ho capito che quando più applicazioni sono presenti, accedendo allo stesso file potrebbe fare alcuni problemi. È il caso di più applicazioni in esecuzione sullo stesso server web? È corretto anche quando viene utilizzato l'output di stdout predefinito?

2- Nella biblioteca Logback C'è una modalità prudente:

In modalità prudente, FileAppender in modo sicuro scrivere sul file specificato, anche in presenza di altri casi FileAppender esecuzione in diverse JVM, potenzialmente in esecuzione su padroni di casa diversi Il valore predefinito per la modalità prudente è falso.

Voglio sapere se l'utilizzo di Logback è favorevole solo su più JVM o è anche vantaggioso per più applicazioni in esecuzione sullo stesso server Web? In caso contrario, è identico a log4j in questo aspetto?

Grazie

risposta

1
  1. Sì. In generale, il tuo principio dovrebbe essere quello di scrivere un file di registro diverso per ogni applicazione (web o no). L'alternativa è che lasci il server al server per decidere sul file da scrivere. JBoss ha modi per disconnettersi genericamente, che andranno allo stesso file. Tuttavia, preferisco comunque avere un registro separato per ogni applicazione.
  2. Per quanto ne so, sia log4j che Logback puntano ad essere minimi nel sovraccarico che possono causare l'applicazione, quindi è improbabile che ce ne sia uno che sia più favorevole. Se più JVM sono essenziali per te, credo che Logback sia più bravo a gestirlo, ma utilizzarlo al di fuori non è una cattiva idea.
3

C'è una cosa che deve essere chiarito: Ci saranno problemi quando diverse istanze di Log4j sono scrittura allo stesso file contemporaneamente, sia in esecuzione nella stessa JVM o meno.

Quando si utilizzano server (e diversi classloader) è possibile avere una singola istanza di server o più istanze di Log4j, a seconda della distribuzione e della configurazione.

  1. Vedere sopra. Lo stdout può subire lo stesso problema misto di output, ma non quando si ruotano i file.
  2. La modalità prudente di logback riguarderebbe la scrittura simultanea di istanze diverse (stessa JVM o meno). Se la tua configurazione utilizza un'istanza Log4j a livello di server, non c'è alcun vantaggio per questo aspetto.
+0

Possiamo elaborare quali sono i problemi? Sono questi: righe miste, contenuto misto in una riga, log persi, problemi con il nome del file rolling? – j23

15

In entrambi log4j e logback se più FileAppender istanze scrivono allo stesso file di registro, c'è un alto rischioper il suddetto file di log corrompersi. Se le istanze FileAppender eseguite sulla stessa JVM o JVM diverse è irrilevante, vale a dire il rischio di corruzione è lo stesso.

Come menzionato nei documenti, in FileAppender eviterà la corruzione prudent mode di logback, anche in presenza di altri FileAppender istanze in esecuzione nello stesso o in diverse JVM, potenzialmente in esecuzione su host diversi. Per impostazione predefinita, la modalità prudente è disabilitata.

La console non può essere danneggiata, quindi la domanda è discutibile.

1

L'utilizzo di Filelocks non è mai effettivamente efficiente/sicuro, quindi durante l'accesso allo stesso file da diversi appendici/lavori di JVM, non è consigliabile. Vedi la configurazione che ho preso direttamente da 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> 

Le altre opzioni per più JVM scrivendo a qualche fonte unificata sono SocketAppenders e il JDBCAppender.

Il JDBCAppender saranno completamente sostituiti in futuro e anche se è non raccomandato neanche. Vedi le registrazioni mailinglist.

SocketAppender potrebbe essere un po 'grezzo, come probabilmente non si stava pianificando di scrivere molto codice per il logback.

C'è un'altra opzione. Potresti usare qualcosa come clusterlog, che è stato creato per risolvere esattamente il tipo di problema che hai.

Problemi correlati