Syslog-ng loggen behavior

Question

Here's the situation:

I have syslog-ng version 3.15. I've noticed that when using TLS and non-TLS transmission, the logs are different.

I have noticed that, when sending logs using the loggen -i (non-TLS, old RFC3164 format) command, I receive the following messages:

Jun 26 18:19:39 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026379, stamp: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD

When using the loggen -i -P (non-TLS, newer RFC5424 format) command the messages look like this:

Jun 26 18:19:28 192.168.1.10 256 <38>1 2018-06-26T18:19:26+03:00 localhost prg00000 1234 - - <U+FEFF>seq: 0000000000, thread: 0000, runid: 1530026366, stamp: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD

When using the TLS loggen -i -U (TLS, old RFC3164 format) command it's not working:

[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

When using the TLS loggen -i -P -U (TLS, newer RFC5424 format) command the logs look like this:

Jun 26 18:19:13 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD

I know the $HOST macro uses the second column to split the logs by host. Having localhost in the second column when using TLS instead of the IP-address can be frustrating when switching between TLS and non-TLS. Can this situation be avoided somehow?

score 2 · Accepted Answer · answered Jul 17 '18 at 07:44

I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg E.g. "256 <13>1 2018-07-09T16:23:25+02:00 localhost ...." tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).

The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.

However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.

Using syslog() source driver would handle (and expect!) framing from loggen or syslog().

Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.

Syslog-ng loggen behavior

1 Answers1