Fluent-bit: [RFC] we have two upcoming out_syslog plugins

[edsiper]

RFC

• https://github.com/fluent/fluent-bit/pull/1601
• https://github.com/fluent/fluent-bit/pull/1551

@manuelluis @ginobiliwang,

first of all thanks for your contribution!

Since two pull requests providing a similar feature has arrived: syslog output plugin, I would like to get for your feedback and input on this matter.

I would like also to ask our community for feedback about the way to proceed; this is not about which PR wins, is about if both are right and both cover the expected features. Should we merge them ?, should we focus on just one ?

please go ahead and write your comments :)

[ginobiliwang]

Excellent, it is a good opportunity for me to participate the community discussion.

[bluebike]

I haven't looked too deeply two implementations, but by default out_syslog should output same what in_syslog inputs (like seen in parsers "syslog-rfc5424"(default?),"syslog-rfc3164-local","syslog-rfc3164"). JSON etc output should be extra/optional feature.

[Benjamintf1]

I think you should focus on https://github.com/fluent/fluent-bit/pull/1601. I think the configuration setup is much better for that interface. Both the ability to specify which tags go into which syslog field, as well as the ability to set structured data and rfc5424 I think are vital to the success of such a plugin.

[corford]

Echoing @Benjamintf1 #1601 looks the most polished and flexible for a remote syslog target.

[corford]

@edsiper do you have any rough timeline or threshold for community feedback before one of these (ideally #1601) could be merged? Asking because at the moment the only way to output to upstream syslog servers is to first forward from fluent bit to a fluentd instance... which is a little cumbersome.

[edsiper]

I did a review of both plugins.

Based on community feedback, features and general API usage (Fluent Bit API), we would stay with #1601 .

While that PR will be merged, there is still more work on it to do like optional JSON formatting, we should discuss that based on use case and community needs.

Thanks everybody for your time on this.