10

logback を使用して syslog を更新しています。これがアペンダーの構成方法です。

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

UDP イベントをリッスンするように rsyslog.conf を更新し、以下の行のコメントを外しました。

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

conf の変更後に syslog デーモンを再起動しました。

すべてのテスト ボックスで、問題なく動作しているようです。ただし、システム syslog の 1 つが私のプロセスによって更新されていません (他のものは問題なく更新されています)。この問題をデバッグするにはどうすればよいでしょうか? 私が考えるべきことはありますか？

アイデアをありがとう

4

1 に答える 1

28

もちろん。大まかに順番に、次の 4 つのテストを試してください。

1. logbackのテスト: 明白なもの: FileAppenderを 2 番目のアペンダーとして追加し、そこにイベントが表示されることを確認します。あなたの投稿は、「それ」がdevで機能することを意味しますが、それがログバックなのかアペンダーなのかわかりませんでした.configスニペットにはappender-refイベントを送信するセクションがありませんSYSLOG.

何も受信しない場合FileAppenderは、アプリ/環境に問題があるか、このサーバーがアペンダーにフィードするイベントを生成していません。

2.メッセージが生成されていることを確認FileAppenderします。

tcpdump -n -i lo -X -s 1500

.. で UDP パケットの完全なペイロードを出力しますlo。アプリでログ メッセージを生成します。宛てのパケットが少なくとも 1 つ表示され127.0.0.1:514ます。そうでない場合は、送信者です。もしそうなら、それはrsyslog構成です。

3. rsyslog がポート 514 にバインドされていることを確認します。

lsof -i:514

または、持っておらずlsof、別のプロセスが 514 にバインドされていないことが確実な場合:

netstat -ln | grep 514

4. rsyslog が受信するものを確認します。イベントがポート 514 に送信されている場合は、ライブ rsyslogd を停止した後、デバッグ モードで再起動し、ターミナルに接続します。

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

イベントの到着が表示されるはずです。それらのいずれも問題を特定しない場合、それは常軌を逸したものです。既知の良好な J2EE および syslog 環境で動作するlogback 構成があります。ただし、上記のいずれかでうまくいくことを願っています。

于 2012-04-15T19:22:48.083 に答える