2015-11-12 18 views
5

Sono abbastanza nuovo in Java e log4j2, mi dispiace per la domanda forse strana. Il mio problema è il seguente. Ho scritto un'applicazione che utilizza log4j2 per la registrazione. Il programma analizza i dati e scrive un avviso nel caso in cui la stringa data non possa essere analizzata come desiderato. A volte il programma riceve un sacco di stringhe inaspettate e quindi registra sempre lo stesso messaggio di errore. Quindi, la domanda è, come evitare di registrare lo stesso messaggio di errore più e più volte. Invece, ad esempio, per vedere lo stesso messaggio di errore 2000 volte nel file di log, vorrei avere un suggerimento nel file di log che questo messaggio di errore sia stato scritto x-times. Il mio attuale file di aspetto log4j2 config come segue:Come sopprimere i messaggi duplicati in log4j2

<?xml version="1.0" encoding="UTF-8"?> 
<Configuration> 
    <Properties> 
     <Property name="pattern">%d{DEFAULT} %-5p %-18.18c %4.4L [%-15.15t] %m%n</Property> 
    </Properties> 

    <Appenders> 
     <Console name="STDERR" target="SYSTEM_ERR"> 
      <PatternLayout pattern="${pattern}" /> 
     </Console> 
    </Appenders> 
    <Loggers> 
     <Root level="warn"> 
      <AppenderRef ref="STDERR" /> 
     </Root> 
    </Loggers> 
</Configuration> 

risposta

0

io purtroppo non hanno il codice a me attualmente, ma questo è come si può risolvere questo (e ci potrebbe benissimo essere una soluzione già là fuori).

È possibile creare un nuovo appender che registri in modo asincrono sul proprio file/console.

Nell'appender è possibile implementare autonomamente l'aggregazione. Ogni volta che arriva un evento di log, invece di scriverlo immediatamente, controlla se hai già visto il messaggio. Se lo hai fatto, invece di loggarlo, incrementa il tuo contatore.

Eventualmente, trasformare tali eventi di registro aggregati in un messaggio aggregato ed elaborare quello anziché i mille eventi del registro.

Questo potrebbe essere risolto (ad esempio) con un secondo operatore sulla base dell'appender asincrono. Di solito (sto osservando il lockback, ma presumo che sia abbastanza simile per te), gli appendici asincroni finiscono per aggiungere eventi a una coda che verrà elaborata da un thread diverso che funziona fuori da quella coda.

È possibile avere una coda diversa per i messaggi aggregati e un operatore che viene eseguito dice ogni 5 secondi. Se in quei 5 secondi lo stesso messaggio è stato visto più volte, il tuo operatore può aggregare quel messaggio e metterlo in coda per essere elaborato in modo che alla fine finisca nei log.

Mi auguro che aiuta,

Artur

P.S .: Per quanto riguarda la propria configurazione, è sufficiente sostituire il Console appender con la vostra abitudine aggregazione appender. Se vuoi console, estendi semplicemente quell'appender e fagli fare quello che vuoi che faccia :)

+0

In realtà si potrebbe avere senso per avere piuttosto una generica AppenderWrapper delegando al vostro Appender attuale. In questo modo puoi facilmente passare facilmente alle appendici se non ti piace più l'appender della console. – philnate

+0

È possibile ottenere lo stesso risultato utilizzando un filtro. Il filtro può essere fornito con un numero di modelli da abbinare agli eventi. Se il filtro corrisponde a un modello, lo alimenta in una memoria in memoria e interrompe la propagazione dell'evento. Il bean di memoria in-memory può quindi avere un worker che utilizza semplicemente un vecchio log per registrare la tua aggregazione (assicurati di scrivere shit quando si spegne).In questo modo puoi semplicemente riutilizzare tutti i tuoi aggregatori e far filtrare il filtro. – pandaadb

0

Ovviamente è possibile creare un plugin log4j2 che faccia questo, ma direi che la libreria di logging non è la migliore posto per affrontare questo.

Penso che ci si ritroverà con un codice molto più semplice se nella propria applicazione si tiene traccia del messaggio precedente registrato. Se il messaggio successivo sarà lo stesso, non registrare ma incrementare un contatore. Quando si preme un altro messaggio, si registra il valore del contatore.

(questo può essere reso più generale con un Dequeue per tenere traccia più messaggi.)

Problemi correlati