2012-04-15 15 views
9

Sto usando logback aggiornare syslog, è così che ho configurato il mio appender:Cercando di problema debug con logback syslog appender non aggiornare syslog

<appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender"> 
     <syslogHost>localhost</syslogHost> 
     <facility>LOCAL0</facility> 
     <suffixPattern>[%thread] %logger %msg</suffixPattern> 
    </appender> 

ho aggiornato rsyslog.conf ad ascoltare per eventi UDP, senza commenti la sotto le righe:

Daemon syslog riavviato dopo le modifiche di conf.

Su tutte le mie caselle di prova, sembra funzionare bene! Tuttavia, uno sul sistema syslog non viene aggiornato dal mio processo (altre cose lo stanno aggiornando bene), mi chiedo come potrei fare il debug di questo problema? Qualcosa che dovrei esaminare mi viene in mente?

Grazie per qualsiasi idea

risposta

25

Sicuro. Liberamente in sequenza, provare questi 4 test:

1. Prova logback: L'ovvia: aggiungere un FileAppender come seconda appender e assicurarsi che gli eventi visualizzati. Il tuo post implica che "it" funziona in dev ma non ero sicuro che si tratti di logback o dell'appender e il frammento di configurazione non ha una sezione appender-ref per inviare eventi a SYSLOG.

Se il tuo FileAppender non riceve nulla, si tratta di un problema di app/ambiente o questo server non sta generando eventi che alimentano l'appender.

2. messaggi Confermare vengono generati: Supponendo che il FileAppender riceve messaggi ma syslog contrario, eseguire:

tcpdump -n -i lo -X -s 1500

.. per l'uscita del pieno carico utile di pacchetti UDP sulla lo. Fai in modo che la tua app generi un messaggio di log. Dovresti vedere almeno 1 pacchetto destinato a 127.0.0.1:514. Se non lo fai, è il mittente. Se lo fai, è la configurazione di rsyslog.

3. Verificare che rsyslog è destinata a porta 514:

lsof -i :514

o se non si dispone di lsof e siamo sicuri che un altro processo non è tenuta a 514:

netstat -ln | grep 514 

4. Vedere che rsyslog riceve: Se gli eventi vengono inviati alla porta 514, dopo aver arrestato il rsyslogd live, riavviarlo in modalità di debug e collegato al terminale:

/etc/init.d/rsyslog stop 
rsyslogd -d 

Si dovrebbero vedere gli eventi in arrivo. Se nessuno di questi identifica il problema, è qualcosa fuori mano. Ho un funzionamento logback config su ambienti J2EE e syslog di buona reputazione. Speriamo che una delle cose di cui sopra lo farà, comunque.

+0

Ottima risposta e molte grazie! Sembra che la causa del problema sia un altro processo legato a 514, sta funzionando bene ora che ho corretto quello. – Hoofamon

+0

Ottima risposta! Mi ha aiutato molto, grazie! –

+0

Sì! Grazie - ottima guida. – borodark