Read, decode, and ship <syslog> without leaving the browser.

Reference

A quick primer on syslog

Syslog is the lingua franca of operational logging. It began life on BSD Unix in the 1980s, was documented after the fact as RFC 3164, and was later modernised into RFC 5424. Despite its age it is still how the vast majority of network gear and servers report what they are doing — a Cisco switch, a pfSense firewall, an Ubuntu host, and a Java application can all ship to the same collector because they all speak syslog.

Anatomy of a message

Every syslog message starts with a priority value in angle brackets, such as <34>. That number packs two pieces of information: the facility, which says which subsystem produced the message, and the severity, which says how urgent it is. After the priority comes a header — a timestamp, the hostname, and in RFC 5424 an app-name, process ID, and message ID — followed by optional structured data and the free-form message text. The syslog parser breaks any line into exactly these parts.

Facility and severity

The priority is computed as facility * 8 + severity. There are 24 facilities (0–23), including kern, auth, daemon, and the eight local0–local7 slots reserved for your own use. There are 8 severities, from emerg (0, the system is unusable) down to debug (7). If you ever need to go from a priority number back to its parts, or the other way around, the PRI calculator does it both ways.

Getting logs where they need to go

Reading a message is half the job; the other half is shipping it. On Linux that usually means rsyslog or syslog-ng forwarding selected facilities and severities to a central host over UDP or TCP. On network hardware it is a few logging lines. The config generator writes a starting configuration for all three. And when your destination is a SIEM rather than a plain collector, the JSON and CEF converter reshapes a message into something a pipeline can index.