Syslog RFC Versions

So last time we talked I was blogging about Syslog protocol selection and I'd like to think I hit the high points on the mark. One area I forgot to talk about was Syslog RFC versions.

Now, I'd like to think we all just accept the default of "RFC 3164" but that is far from reality.

You see, when Syslog was born it was the only option. No standards document, no group of geeks arguing if they needed a nibble or word of data for a field. Nope. It was just sorta... built and deployed.

Later on we got RFC 3164, which served our needs in a pre-NAT world and is the standard to this date.

What happens if you NAT? What if you need to use Syslog over TLS with a load balancer? We can no longer rely on critical fields from the datagram head itself. The protocol needs to extend its own internal meta-datafield so they are not lost in an environment where the datagram integrity would change .

In comes RFC 5424.

Basically, to get around network manipulation and provide some metadata structure we got the following fields added: app-name, procid, msgid, structured-data and msg.

With the addition of this "structured-data" field your favorite Syslog engine (rsyslog/Syslog-ng) could now store information in a structured way that wouldn't get lost. Mostly this ends up being receiving host, IP addresses and that sort of thing.

Since it relies on on the Syslog implmentation to use the field AND use RFC 5424, I have personally only seen this used once in production - and the entire stack was bound to Syslog-ng and had major interoperability problems with Rsyslog.

Summary For the most part, the industry isn't using RFC 5424; we're using Splunk Forwarders, Beats and logging over HTTPS. But, if you have to do special routing where some structured data needs protection in the Syslog datagram. RFC 5424 is your option!