状況はこんな感じです。
syslog-ngバージョン3.15があります。 TLS と非 TLS 転送を使用すると、ログが異なることがわかりました。
loggen -i
(TLSではなく、以前のRFC3164形式)コマンドを使用してログを送信すると、次のメッセージが表示されます。
6月26日 18:19:39ローカルホストprg00000[1234]: seq: 0000000000、スレッド: 0000、runid: 1530026379 DPADDPAD DPADDPADDD
(TLSではなく最新のRFC5424形式)コマンドを使用すると、loggen -i -P
メッセージは次のようになります。
6月26日 18:19:28192.168.1.10 256<38>1 2018-06-26T18:19:26+03:00ローカルホストprg00000 1234 - - <U+FEFF> seq: 0000000000, スレッド: 0000, runid: 1530026366, スタンプ: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADD DPADDP ADDPADPADDPADPAD
TLS loggen -i -U
(TLS, 以前の RFC3164 形式) コマンドを使用する場合は機能しません。
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
TLS loggen -i -P -U
(TLS, 最新 RFC5424 形式) コマンドを使用する場合、ログは次のようになります。
6月26日 18:19:13ローカルホストprg00000[1234]: seq: 0000000000, スレッド: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDD ADDPADDPAD
$HOSTマクロは、2番目の列を使用してホストごとにログを分割することを知っています。 TLSと非TLSを切り替えるときに2番目の列の代わりにTLSを使用するのは残念ですlocalhost
。IP-address
どういうわけかこの状況を避けることができますか?
答え1
問題はフレームにあることがわかりました。 syslog-ng と loggen の syslog() ドライバはメッセージ長 + msg 例: "256 <13>1 2018-07-09T16:23:25+02:00 localhost . ..."送信します。一方、tcp()またはnetwork()ドライバはRFC5424形式のメッセージを解析できますが(flags(syslog-protocol)オプションが使用されている場合)、フレーミングを期待しません。
回避策は、loggenでフレーミングを無効にし(loggenに「-F」オプションを使用)、network()ソースで「flags(syslog-protocol)」オプションを使用することです。
ただし、これはloggenの問題のみを解決します。ログソースがフレーム化されたログメッセージを送信すると、tcp()ソースドライバに同じ問題が発生します。
syslog()を使用すると、ソースドライバはloggenまたはsyslog()のフレームを処理して期待します。
しかし、tcp()、upd()ドライバは廃止され、syslog-ngに応じて最新のnetwork()ドライバを使用することをお勧めします。文書。