Differences between TCP and UDP log processing?

[gsl_ops_practice]

Hello,

Due to various constraints in a new environment we need to use UDP/514 to send logs from application servers to NagiosLog. In other environments with TCP logging, in the rsyslog.d/configuration I am specifying the highlighted lines as per below and logstash parses it no problem and I get a field with "program" that I can then use to parse the logs as needed. When changing that from @@nagioslogserver:5544 TCP to @nagioslogserver:514 for UDP, NagiosLog no longer picks up the Program field. Can you please advise?

$ModLoad imfile
$InputFilePollInterval 10
$PrivDropToGroup adm
$WorkDirectory /var/lib/rsyslog/

# Input for gg1trsV2
$InputFileName /some/path/transaction.log
$InputFileTag someLogV2:
$InputFileStateFile nls-state-some-path-transaction-log # Must be unique for each file being polled
# Uncomment the folowing line to override the default severity for messages
# from this file.
#$InputFileSeverity info
$InputFilePersistStateInterval 20000
$InputRunFileMonitor

# Forward to Nagios Logserver and then discard.
if $programname == 'someLogV2' then @@nagioslogserver:5544
if $programname == 'someLogV2' then ~

[cdienger]

If you're using a udp input then the message will not parse correctly. You can have multiple syslog inputs though on different ports. Please provide a copy of the input config if this doesn't help resolve the problem.

[vAJ]

+1 on filters being mapped to the correct input.

That said, another limitation of UDP vs TCP is in the message size. UDP has a 1Kb limitation, TCP is 8Kb. Found this out the hard way when some of our app logs were sending >1k JSON messages and it was failing to parse. When I looked closely, the tailing closing brackets of the JSON messages were just barely over the 1K limit...

[cdienger]

Thanks for the heads up, Andrew!

[gsl_ops_practice]

Hello everyone,

Thanks on the UDP vs TCP message size limitation, that may explain some of the weirdness we are seeing as well. I stopped using the UDP input explicitly and just remapped syslog to 514 and that seems to work.

Will advise when we have this worked out properly on our side, still in the testing phase.

Best regards,
Alex

[cdienger]

Thanks for the update!