Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP listener for syslog server #9

Open
DavidGamba opened this issue Nov 4, 2017 · 5 comments
Open

UDP listener for syslog server #9

DavidGamba opened this issue Nov 4, 2017 · 5 comments

Comments

@DavidGamba
Copy link
Contributor

There are still plenty of pieces of software that send syslog messages over UDP. It would be nice to be able to use this library to receive those and not rely on other syslog servers.

@nathanaelle
Copy link
Owner

maybe …

Providing an UDP collector is like providing the possibility to crypt with a raw MD5 : if it's possible then some one will use it stupidly.

@DavidGamba
Copy link
Contributor Author

My particular use case is to collect logs from a java application that uses logback, a popular logging framework. Unfortunately the logback syslog appender doesn't support TCP at all so I need to support UDP. I currently use rsyslog to collect logs but it would be nice to be able to collect them with this library.

The syslog 5424 does talk about maintaining support for UDP briefly:

This document does not specify any transport layer protocol.
   Instead, it describes the format of a syslog message in a transport
   layer independent way.  Syslog transports are defined in other
   documents.  One such transport is defined in [RFC5426] and is
   consistent with the traditional UDP transport.  This transport is
   needed to maintain interoperability as the UDP transport has
   historically been used for the transmission of syslog messages.

https://tools.ietf.org/html/rfc5424

But then again, if you feel like not adding support for it that is alright too... Thanks for the great library, already use it in production to send syslog messages from both linux and windows.

@nathanaelle
Copy link
Owner

I know… for 8 years, the RFC recommands that a server SHOULD implement UDP server.

the same RFC 5424 says :

All transport receiver
implementations SHOULD be able to accept messages of up to and
including 2048 octets in length.  Transport receivers MAY receive
messages larger than 2048 octets in length.

the older RFC 3164 says :

If the packet has been expanded beyond
1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.

Actually lots of people yell against systemd just because systemd truncate the showed log (not the stored one) in paginate mode without any knowledge of thoses historical points.

I show you thoses points, because my main concern behind this lib is to gain some reliability improvement in my syslog infrastructure, and TCP is more reliable than UDP, like "logging the full message" is more reliable and provide better audit material than the respect of "truncate because RFC says so".

I understand your concern about UDP… and maybe I will implement an UDP collector (without any truncation … except for the 64kb limit of UDP datagram 😅), but not now.

I don't know the actual good practices about Java and logging, but is there any "plugin" for Logback ?

@nathanaelle
Copy link
Owner

I'm sorry my previous answer may be misinterpreted.

I don't judge anyone, I just tried to show the expectation of admins about syslog : logging all the untruncated messages.

UDP is lossy transport, so there is alot of packet loss with UDP.
in case of UDP syslog, 1% of UDP loss means 1% of syslog loss…

@nathanaelle
Copy link
Owner

TCP may have loss.
but 1% of TCP loss means that one has some huge network issue.
TCP has mecanism like TCP retransmission, packet ACK, that avoid most of the loss.
with TCP keepalive, you also have the possibility to detect some cases that are not handled by other mecanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants