syslog parser
Syslog parser, viewer & validator
Paste a raw syslog line and read it as structured fields. The parser splits out the priority, decodes facility and severity, lays out the timestamp, host, application, and message, and checks the line against the RFC 5424 standard — flagging anything that doesn't conform. Works with both RFC 5424 and the older RFC 3164 / BSD format.
Every field conforms to the RFC 5424 grammar.
| Timestamp | 2003-10-11T22:14:15.003Z |
| Hostname | mymachine.example.com |
| App-name | su |
| Proc-ID | — nil |
| Msg-ID | ID47 |
| Message | 'su root' failed for lonvick on /dev/pts/8 |
Guide
What a syslog parser actually does
A raw syslog line is a single dense string with no obvious boundaries. A parser’s job is to recover the structure the sender encoded into it: the priority value, the header fields, any structured data, and the human-readable message. Once those parts are separated you can filter on severity, group by host, route by facility, or forward only what matters. The tool above does this on whatever you paste and colour-codes the severity using the same eight-level scale the rest of the site uses.
Validating against RFC 5424
Detecting a format is not the same as checking conformance, so the parser does both. Whenever a line has the RFC 5424 shape — a version number after the priority, like <34>1 — it is also validated against the standard’s grammar, and a verdict appears above the field breakdown: a green Valid RFC 5424, or a list of the exact problems found. Paste the “Invalid” example above to see it flag a missing time zone.
The validator checks the things that most often break a message:
- PRI is a number from 0 to 191 with no leading zeros, and a non-zero version follows it.
- Header fields are separated by exactly one space, and TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID, and STRUCTURED-DATA are all present.
- The timestamp is valid RFC 3339 — an uppercase
TandZ, a time zone, and at most six fractional-second digits. - Length limits hold: HOSTNAME ≤ 255, APP-NAME ≤ 48, PROCID ≤ 128, and MSGID ≤ 32 printable-ASCII characters.
- Structured data is well formed: namespaced SD-IDs, double-quoted parameter values, and the characters
",\, and]escaped inside those values.
RFC 3164 messages are reported as “not applicable” rather than failed, because the BSD format has no strict grammar to validate against. To assemble a compliant line from scratch instead of checking one, the RFC 5424 builder emits the correct field order and nil values for you.
The fields, one by one
Priority (PRI)
Every well-formed message opens with a priority in angle brackets, such as <34>. It encodes two numbers at once. The facility is PRI ÷ 8 and identifies the subsystem that produced the message; the severity is PRI mod 8 and says how urgent it is. So <34> is facility 4 (auth) and severity 2 (critical). To go between a priority value and its parts in either direction, use the PRI calculator.
Header
After the priority comes the header. In RFC 5424 it is a fixed, space-separated sequence: a version digit, an ISO 8601 timestamp, the hostname, the app-name, the process ID, and a message ID. In RFC 3164 the header is looser — a non-year timestamp like Oct 11 22:14:15, the hostname, and a tag such as sshd[1234] that the parser splits into an application name and a process ID.
Structured data and message
RFC 5424 adds an optional structured data block — one or more bracketed elements like [exampleSDID@32473 iut="3"] carrying typed key/value pairs. Everything after that is the free-form message. The parser renders structured data as a readable list of parameters; for the full grammar see the RFC 5424 reference.
Viewing syslog on Linux
Most people reach for a parser because they are staring at a log file. Where that file lives depends on the distribution:
- Debian / Ubuntu:
/var/log/syslogholds general system messages; authentication events go to/var/log/auth.log. - RHEL / CentOS / Fedora: the equivalent is
/var/log/messages, with security events in/var/log/secure. - systemd hosts: the journal is the source of truth. Use
journalctl -fto follow it, orjournalctl -o short-isofor timestamps that look like RFC 5424.
To watch messages arrive in real time, tail -f /var/log/syslog is the classic move; pipe it through grep to narrow to one host or daemon. Copy any line that interests you and drop it into the parser to see its fields broken out.
Parsing syslog in code
For one-off inspection the tool above is enough, but in a pipeline you will want to parse programmatically. A few pointers:
- Prefer a real grammar over a single regex. RFC 5424 structured data can contain escaped brackets and quotes inside parameter values, which a naive regex will mis-split. Consume the bracketed elements with a small scanner instead.
- Python: the standard
logging.handlers.SyslogHandleremits syslog, and libraries such assyslog-rfc5424-parserread it back. For quick work, split on the first few spaces after the PRI and parse the timestamp withdatetime.fromisoformat. - Pipelines: Logstash, Fluentd, and Vector all ship syslog parsers; feed them the raw line and they emit structured events. When the destination is a SIEM, the JSON and CEF converter shows the shape you are aiming for.
Frequently asked questions
- Can this validate whether a message follows RFC 5424?
- Yes. When a line has the RFC 5424 shape (a version number after the priority, e.g. <34>1), the parser checks it against the standard and shows a verdict above the field breakdown — either 'Valid RFC 5424' or a list of the specific problems it found. RFC 3164 / BSD lines are marked 'not applicable' because that older format has no strict grammar to check against.
- What does the validator check for?
- The PRI is in range (0–191) with no leading zeros and is followed by a non-zero version; header fields are separated by single spaces and all present; the timestamp is valid RFC 3339 (uppercase T and Z, a time zone, at most six fractional digits); HOSTNAME, APP-NAME, PROCID, and MSGID stay within their length limits and use printable ASCII; and structured data is well formed with quoted values and properly escaped characters.
- How do I read a syslog message?
- Start at the angle-bracket priority value, e.g. <34>. Divide it by 8 for the facility and take the remainder for the severity. After the priority comes the header — a timestamp, the hostname, and in RFC 5424 the app-name, process ID, and message ID — and then the free-form message text. Paste any line into the parser above and each of these parts is labelled for you.
- Does this syslog parser work with both RFC 5424 and RFC 3164?
- Yes. The parser auto-detects the format. If a version digit follows the priority (for example <34>1) it is treated as RFC 5424; otherwise it falls back to a lenient RFC 3164 / BSD parse that handles the classic 'Mmm dd hh:mm:ss host tag[pid]: message' shape.
- Is my log data uploaded anywhere?
- No. Parsing happens entirely in your browser with client-side JavaScript. Nothing you paste is sent to a server, so it is safe to use with production logs that may contain hostnames, IP addresses, or other sensitive details.
- Why does a field show as nil?
- RFC 5424 uses a single hyphen ( - ) as the NILVALUE to mean 'this field has no value'. The parser shows those as 'nil' rather than guessing. Process ID and message ID are the fields most often sent as nil.
- How do I view the syslog file on a Linux server?
- On Debian and Ubuntu the main file is /var/log/syslog; on RHEL, CentOS, and Fedora it is /var/log/messages. Use 'tail -f /var/log/syslog' to follow it live, or 'journalctl -f' on systemd hosts. Copy a line from there and paste it above to break it into fields.