JBoss logging
la configurazione di default della componente log4j di JBoss non è certamente adatta agli ambienti di produzione per diversi motivi: vediamo quali.
Innanzitutto l'appender su file presenta due caratteristiche non adatte ad ambienti ad alto accesso: non è configurato in append ed il livello di logging non è limitato.
Il parametro append, esplicitamente impostato a false, fa si che ogni riavvio dell'application server comporti la completa perdita di tutti i log della giornata (solo della giornata per l'appender è in rotazione giornaliera) e questo, come potete immaginare, può essere un problema grave per la diagnosi di problemi.
In secondo luogo l'assenza del parametro Threshold consente a tutti i tracciamenti che superano il filtro globale di finire all'interno del file di log: questa impostazione potrebbe non essere ottimale se l'applicazione presenta numerosi statement di log a livello DEBUG. Se siamo in questo specifico caso la soluzione più semplice è quella di impostare il parametro menzionato al livello INFO, ma questo ci impedirebbe di raccogliere eventuali preziosi log per la risoluzione di anomalie. Una soluzione più efficace ed efficente è quella di filtrare gli statement che rendono il nostro file di log troppo grosso usando una direttiva del tipo
che limita il livello di log di una specifica categoria (o package) ancora prima che questo venga reindirizzato verso il file.
Una ulteriore ottimizzazione possibile sulla dimensione dei file di log è procedere periodicamente alla loro compressione che può portare enormi benefici vista la tipologia di dati in essi contenuta. Un semplice script eseguito giornalmente da cron può essere una valida soluzione:
Innanzitutto l'appender su file presenta due caratteristiche non adatte ad ambienti ad alto accesso: non è configurato in append ed il livello di logging non è limitato.
Il parametro append, esplicitamente impostato a false, fa si che ogni riavvio dell'application server comporti la completa perdita di tutti i log della giornata (solo della giornata per l'appender è in rotazione giornaliera) e questo, come potete immaginare, può essere un problema grave per la diagnosi di problemi.
In secondo luogo l'assenza del parametro Threshold consente a tutti i tracciamenti che superano il filtro globale di finire all'interno del file di log: questa impostazione potrebbe non essere ottimale se l'applicazione presenta numerosi statement di log a livello DEBUG. Se siamo in questo specifico caso la soluzione più semplice è quella di impostare il parametro menzionato al livello INFO, ma questo ci impedirebbe di raccogliere eventuali preziosi log per la risoluzione di anomalie. Una soluzione più efficace ed efficente è quella di filtrare gli statement che rendono il nostro file di log troppo grosso usando una direttiva del tipo
<category name="org.jboss.management">
<priority value="INFO"/>
</category>
che limita il livello di log di una specifica categoria (o package) ancora prima che questo venga reindirizzato verso il file.
Una ulteriore ottimizzazione possibile sulla dimensione dei file di log è procedere periodicamente alla loro compressione che può portare enormi benefici vista la tipologia di dati in essi contenuta. Un semplice script eseguito giornalmente da cron può essere una valida soluzione:
find /tmp/log/ -regextype posix-basic -regex '.*server.log..*[0-9]' -exec gzip '{}' +
posted by Unknown at
11:53 PM
|
1 comments
