Fluent-bit: udp json input support

Created on 3 Apr 2019  路  13Comments  路  Source: fluent/fluent-bit

Is your feature request related to a problem? Please describe.
There is currently a json tcp input, but no corresponding option for udp

Describe the solution you'd like
Having the ability to consume json events sent over udp would be beneficial

waiting-for-user

Most helpful comment

Reliably transporting logs sent from applications via UDP.

In some instances it is desirable for the application to emit logs via UDP rather than handle reconnection/buffering/blocking/etc in the application where dropping logs in the event of logging infrastructure failures are acceptable. The main problem with this approach is that sending UDP over the network offers very little guarantees.

A pattern I have used is ingesting UDP logs over localhost to a local agent, which in turn then takes care of buffering and reliably sending over the network. This pattern can be achieved today with the in_udp fluentd input, Logstash, or nxlog. The downside is the former two agents are quite heavyweight, while nxlog meets the lightweight requirement it's capabilities are rather limited compared to eg fluent-bit.

The use-case is similar to syslog ingestion over tcp vs udp which I note fluent-bit supports both today.

All 13 comments

would you please elaborate your use case ?

Reliably transporting logs sent from applications via UDP.

In some instances it is desirable for the application to emit logs via UDP rather than handle reconnection/buffering/blocking/etc in the application where dropping logs in the event of logging infrastructure failures are acceptable. The main problem with this approach is that sending UDP over the network offers very little guarantees.

A pattern I have used is ingesting UDP logs over localhost to a local agent, which in turn then takes care of buffering and reliably sending over the network. This pattern can be achieved today with the in_udp fluentd input, Logstash, or nxlog. The downside is the former two agents are quite heavyweight, while nxlog meets the lightweight requirement it's capabilities are rather limited compared to eg fluent-bit.

The use-case is similar to syslog ingestion over tcp vs udp which I note fluent-bit supports both today.

I got pretty much the same case that @nvx, so i'd like to vote up for this feature.

Same scenario here - are there any plans to make that happen?

Likewise, would be nice to have UDP input

+1 for UDP input, we would like to replace rsyslog forwarder with fluent-bit

Is there still any information needed? I notice the awaiting for user label is still on this @edsiper

Is there any timeline/update for this? UDP input would be a HUGE win for streaming logs with fluent bit.

Actually in_syslog could be used as _generic_ UDP input.. .just by giving suitable parser.
I thought that if we just take in_syslog and copy it to as in_udp (some search/replace).
Then add right method to parse tag name from message... and we have generic UDP input.

Also this could be used for something like in_influxdb for influxdb line protocol with UDP.
In that case it would better to InfluxDB line protocol parser (regex is not really enough for that).

We have this use case. I'm an engineer at New Relic and we would like to be able to offer this option to our users who use fluentbit as a forwarder.

@JimHagan Few weeks ago I copied in_syslog to in_udp ... replaces syslog to udp...
and did some testing (didn't have to time do more...)
I could try to make PR in few days..

I made PR #2414 in_udp module...
@nvx @JimHagan You could have test... or give comments if module would cover your needs.

I have tested it only in my macOS (10.13) so far.

One further use case:

Sending kernel and early user space (initramfs) logs via the netconsole kernel module over UDP before any other logging daemon is running during system boot.

I use that with Coinboot for a huge number of diskless nodes without any KVM over IP capabilities for debugging early boot stages.
These kernel message don't align with RFC 3164 or RFC 5424 and so fail to be ingested by the in_syslogmodule.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brycefisher picture brycefisher  路  3Comments

lbogdan picture lbogdan  路  3Comments

jcdauchy-moodys picture jcdauchy-moodys  路  3Comments

c0ze picture c0ze  路  3Comments

benclive picture benclive  路  3Comments