Open DavidGamba opened 7 years ago
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.
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.
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 ?
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…
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.
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.