2

I'm taking syslog events from a proprietary app. This could be the app's fault or it could be rsyslogd.

Events are written like:

Aug 15 16:00:00 10.11.12.13 Event1 from this wonderful product using this odd
Aug 15 16:01:00 10.11.12.13 format. Event2 from this wonderful product using 
Aug 15 16:02:00 10.11.12.13 this odd format. Event3 from this wonderful produ
Aug 15 16:03:00 10.11.12.13 ct using this odd format.

you get the picture. Each record in syslog is ~2000 characters.

I'm not sure if this is an issue with the poorly defined nature of TCP syslog?

Does any expert on rsyslogd or syslog TCP have any advice as to where the problem might be? Is it likely that there's something I can do on the rsyslogd side to fix this? Or is this a normal mess for the state of TCP syslog?

1 Answer 1

1

rsyslogd is not configured to break lines like that. It's possible to use log format templates but I'm not sure they allow lines to be broken like that. This is most likely what the application is sending to rsyslogd.

You can try to capture the communication on port and check what is being sent (tcpdump -s 0 -A port 514).

Another test is to use logger to write a really long line. In my tests, rsyslogd wrote it as just a single line (no wrapping).

2
  • I'll set up the trace and see if I can find a line termination character, it's possible something is being ignored. Templates sound like a good place to start looking.
    – mgjk
    Aug 16, 2014 at 12:43
  • the admin of the source device changed things over to UDP and everything works now. Downside was that I didn't get my network trace.
    – mgjk
    Aug 19, 2014 at 17:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .