情况如下:
我有 syslog-ng 版本 3.15。我注意到,当使用 TLS 和非 TLS 传输时,日志是不同的。
我注意到,当使用loggen -i
(非 TLS,旧 RFC3164 格式)命令发送日志时,我收到以下消息:
6月26日 18:19:39本地主机prg00000[1234]:序列号:0000000000,线程:0000,runid:1530026379,戳记:2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
当使用loggen -i -P
(非 TLS,较新的 RFC5424 格式)命令时,消息如下所示:
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 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
当使用 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]:序列号:0000000000,线程:0000,runid:1530026353,戳记:2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
我知道 $HOST 宏使用第二列按主机拆分日志。localhost
使用 TLS 而不是第二列时,IP-address
在 TLS 和非 TLS 之间切换时可能会令人沮丧。可以以某种方式避免这种情况吗?
答案1
我发现问题在于框架。syslog-ng 和 loggen 中的 syslog() 驱动程序也会发送带有框架的 RFC5424 格式的消息:消息长度 + 消息,例如“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() 驱动程序已经过时,建议使用较新的 network() 驱动程序(如 syslog-ng 的驱动程序)文档。