rfc 5424
RFC 5424 format reference & builder
The modern syslog message format, explained field by field — with an interactive builder that assembles a compliant line as you type. Fill in the parts you have and leave the rest blank to emit the correct nil values.
<14>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="App"] An application event log entry...Empty header fields are emitted as the NILVALUE - as the spec requires. The order is fixed: PRI, VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID, STRUCTURED-DATA, then MSG.
Reference
The RFC 5424 message format
RFC 5424 defines a syslog message as a header, optional structured data, and an optional message, in that order. The whole thing is a single line, and the header fields are separated by exactly one space. Written out, the shape is:
<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG
The strictness is the point. Because the order and separators are fixed, a collector can parse the header without guessing, and because every absent value is written as a hyphen, there is no ambiguity between “empty” and “missing”. The syslog parser relies on exactly these rules to read a line back into fields.
An annotated example
Take the canonical example from the RFC:
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - 'su root' failed for lonvick
| Field | Value | Meaning |
|---|---|---|
| PRI | <34> | Facility 4 (auth), severity 2 (critical) |
| VERSION | 1 | Syslog protocol version — always 1 today |
| TIMESTAMP | 2003-10-11T22:14:15.003Z | RFC 3339 time, here in UTC with milliseconds |
| HOSTNAME | mymachine.example.com | FQDN, hostname, or IP of the sender |
| APP-NAME | su | The program that produced the message |
| PROCID | - | Nil — no process ID supplied |
| MSGID | ID47 | Identifier for this type of message |
| STRUCTURED-DATA | - | Nil — no structured data |
| MSG | 'su root' failed… | Free-form, UTF-8 event text |
Timestamps
RFC 5424 timestamps follow RFC 3339, a profile of ISO 8601. That means a four-digit year, a T separator, and a time zone — either Z for UTC or an offset like +02:00. Fractional seconds are allowed up to six digits. This is a sharp upgrade over the BSD timestamp, which has no year and no time zone, and it is why 5424 logs sort and correlate cleanly across machines. The builder’s now button inserts a correctly formatted current timestamp.
Structured data in depth
Structured data is the most powerful addition in RFC 5424. Each element looks like [SD-ID name="value" name="value"], and a message may carry several elements one after another. The SD-ID is namespaced so that vendors do not step on each other:
- Registered IDs such as
timeQuality,origin, andmetaare defined by the RFC itself and used without a suffix. - Custom IDs append
@and an IANA private enterprise number, for exampleexampleSDID@32473. The number guarantees the namespace is yours. - Inside a parameter value, the characters
",\, and]must be escaped with a backslash. A correct parser honours those escapes when finding the end of an element.
RFC 5424 vs RFC 3164
| Aspect | RFC 3164 (BSD) | RFC 5424 |
|---|---|---|
| Timestamp | Oct 11 22:14:15 — no year, no zone | ISO 8601 with zone and fractional seconds |
| Version field | None | Explicit (1) |
| App / PID | Loose tag, e.g. sshd[1234] | Separate APP-NAME and PROCID |
| Message ID | None | MSGID field |
| Structured data | None | Typed key/value elements |
| Encoding | ASCII in practice | UTF-8 with optional BOM |
Both formats still travel over the same transports and the same default port. If you are choosing for a new system, pick RFC 5424; reach for 3164 only when an old device leaves you no choice. To generate a forwarding configuration for either, use the config generator.
Frequently asked questions
- What is RFC 5424?
- RFC 5424, published in 2009, defines the modern syslog protocol. It replaced the loosely specified BSD format (RFC 3164) with a strict, ordered header, ISO 8601 timestamps, explicit nil values, optional structured data, and full Unicode support in the message. It is the format new deployments should target.
- What does a valid RFC 5424 message look like?
- A canonical example is: <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - 'su root' failed for lonvick on /dev/pts/8. Reading left to right: priority <34>, version 1, timestamp, hostname, app-name 'su', nil process ID, message ID 'ID47', nil structured data, then the message.
- What is the field order in RFC 5424?
- It is fixed: PRI, VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID, STRUCTURED-DATA, then MSG. Every field except the message is separated by a single space, and any header field with no value is sent as a single hyphen ( - ), the NILVALUE.
- What is structured data in RFC 5424?
- Structured data is an optional, machine-readable block of one or more elements, each written as [SD-ID param="value" ...]. The SD-ID is namespaced with an IANA private enterprise number, e.g. exampleSDID@32473, so different vendors can define their own fields without colliding. A message can carry several elements back to back.
- How is RFC 5424 different from RFC 3164?
- RFC 3164 is the original BSD format: a non-year timestamp like 'Oct 11 22:14:15', a hostname, and a tag, with no formal structure beyond that. RFC 5424 adds a version number, precise ISO 8601 timestamps with time zone and fractional seconds, explicit app-name/procid/msgid fields, structured data, and a UTF-8 message. Prefer RFC 5424 unless you must interoperate with old equipment.