Description
When using the Syslog consumer with < RFC6587 you get forced into using UDP for the transport due to strict adherence to the standard. However while correct this prevents you from accepting messages from non-rfc compliant loggers that use TCP.
This is born from a situation I'm currently dealing with using IBM Kubernetes Service where they ship remote logs via dlackty/fluent-plugin-remote_syslog. However payload sizes >1kb get truncated for UDP packets so I'm forced to use TCP. This would be fine but dlackty/fluent-plugin-remote_syslog actually creates syslog messages using RFC3164 which is defined as UDP only so gollum forces the transport from TCP -> UDP and I lose large messages (these are http request logs that can have lengthy json).
The options I've tried to work around this are:
- Make a proxy-consumer on
tcp://0.0.0.0:514
and a producer tounixgram:///var/gollum/proxy
then create the RFC3614 listener on that unix socket, however I seem to get a lot of I/O read errors and drop messages but this might just be my bad config. - Make a TCP socket and attempt to grok the format myself, I dropped this idea as it was more work than 3.
- Patch gollum to remove the forcing to udp which works well, I receive the messages as expected but it feels dirty to have to hack the code and produce my own docker image.
While I understand the why the forcing to UDP is done but I think for Gollum's goal of being a multiplexer with many different flexible input/outputs the strict adherence to the RFCs without the possibility of overriding them limits ingesting messages from sources that might not be RFC compliant and forces you down the path of doing weird spaghetti workarounds.
Here's my proposals on solutions:
- Remove the TCP -> UDP coercion and make the warning loud and obvious.
- Introduce an explicit parameter that allows you to force the protocol
ignoreRFC: true
. - If it is possible come up with an accepted example config for re-routing/proxying TCP syslog traffic to a UDP consumer
Activity