Próba wystawienia debugowania z logback syslog appender nie aktualizowanie syslog

Question

Używam logback zaktualizować syslog, to jak mam skonfigurowany moje appender:

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

zaktualizowałem rsyslog.conf do nasłuchiwania zdarzeń UDP, Odkomentowano pod liniami:

# Provides UDP syslog reception 
$ModLoad imudp.so 
$UDPServerRun 514 

Restartowany demon syslog po zmianach conf.

We wszystkich moich polach testowych wszystko działa dobrze! Jednak jeden systemowy syslog nie jest aktualizowany przez mój proces (inne rzeczy aktualizują go po prostu dobrze), zastanawiam się, w jaki sposób mógłbym przystąpić do debugowania tego problemu? Coś, na co powinienem się przyjrzeć, przychodzi mi na myśl?

Dzięki za wszelkie pomysły

Answer 1

Pewnie. Luźno w sekwencji, spróbuj te 4 testy:

1. Badanie logback: oczywistego: dodać FileAppender jako drugi appender i upewnić się, że pojawiają się tam wydarzeń. Twój post sugeruje, że "to" działa w dev, ale nie byłem pewien, czy jest to logback czy appender, a fragment kodu konfiguracji nie ma sekcji appender-ref do wysyłania zdarzeń do SYSLOG.

Jeśli twój FileAppender nic nie otrzymuje, jest to problem aplikacji/środowiska lub ten serwer nie generuje zdarzeń, które są przesyłane do aplikanta.

2. Potwierdź komunikaty są generowane: Zakładając, że FileAppender odbiera komunikaty syslog ale nie, uruchom:

tcpdump -n -i lo -X -s 1500

.. na wyjściu pełną ładowność pakietów UDP na lo. Spraw, aby Twoja aplikacja generowała komunikat dziennika. Powinieneś zobaczyć przynajmniej 1 pakiet przeznaczony na 127.0.0.1:514. Jeśli nie, to jest nadawcą. Jeśli tak, to jest to konfiguracja rsyslog.

3. potwierdzić, że rsyslog jest zobowiązany do portu 514:

lsof -i :514

lub jeśli nie masz lsof i jesteśmy pewni, że inny proces nie jest zobowiązany do 514:

netstat -ln | grep 514 

4. Zobacz, co rsyslog odbiera: Jeśli zdarzenia są wysyłane do portu 514, po zatrzymaniu live rsyslogd uruchom go ponownie w trybie debugowania i dołącz do terminala:

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

Powinieneś zobaczyć zdarzenia nadchodzące. Jeśli żadna z nich nie identyfikuje problemu, jest to coś na uboczu. Mam działające logback config na dobrze znanych środowiskach J2EE i syslog. Mam nadzieję, że zrobi to jedna z powyższych rzeczy.