rfc·explained

RFC 5424 · · Proposed Standard

Syslog, with a real timestamp at last.

The official title is "The Syslog Protocol." What it actually decides: a proper structure for log messages, precise timestamps, machine-readable fields, so the stream of events from every device stops being a pile of free text.

Status
Proposed standard
Replaces
RFC 3164

Written by Noel Lang · IT trainer

TL;DR

RFC 5424 is the modern syslog message format. It replaced the loose BSD-era format of RFC 3164 with a precise RFC 3339 timestamp (year, timezone, sub-second), clearly named header fields, and an optional structured data section that tools can parse. It standardises what a log line looks like, separate from how it is transported.

The problem it solves

For decades, “syslog” was not really a standard. It was just what BSD Unix happened to do in the 1980s, copied from machine to machine until half the internet spoke it. RFC 3164 came along in 2001 and only wrote that behaviour down, warts and all. It was Informational: an autopsy report, not a rulebook. Its worst legacy is the timestamp. Oct 11 22:14:15 has no year and no timezone, which is close to useless the moment you collect logs from servers in three countries and try to line up what happened when.

RFC 5424 is the deliberate redo. Same idea, a short line describing one event, but with a real, unambiguous format: a full timestamp, named fields for host, app and process, and an optional slot of structured data that machines can actually parse. It defines what a log line looks like, and pointedly leaves how it travels to separate companion documents.

The priority stamp, decoded

Every syslog line opens with a cryptic number in angle brackets, like <165> or <34>. This is the part that puzzles everyone, and it is beautifully simple once you see it. That single number encodes two things at once: which subsystem sent the message (the facility) and how bad it is (the severity).

Think of internal office mail. Every memo gets one stamp that says both which department it came from and how urgent it is, and the mailroom sorts by that stamp without reading a word. Syslog does the same, except it squeezes both halves into one small integer to save space, a very 1980s decision.

The formula is facility times 8, plus severity. Severity is a value from 0 to 7, so it fits in the lowest three bits; everything above that is the facility. So <165> unpacks as facility 20 (local4) times 8, which is 160, plus severity 5 (notice): 165. And <34> is facility 4 (security) times 8, plus severity 2 (critical). Once you can do that little division in your head, the number at the start of the line stops looking like line noise.

The eight severity levels

The half of the priority number people actually search for. Counterintuitively, lower is worse: 0 is a catastrophe, 7 is chatter.

Severity What it means
0 · Emergency System is unusable. The 3 a.m. pager level. In practice almost nothing logs this high.
1 · Alert Action must be taken immediately: a condition that needs a human right now, like a database out of disk space.
2 · Critical Critical conditions. A component has failed, for example a hardware fault or a lost primary connection.
3 · Error Error conditions. Something did not work: a request failed, a file could not be written. The everyday "something is wrong" level.
4 · Warning Not broken yet, but heading there: a disk 85% full, a deprecated call, a retry that succeeded on the second try.
5 · Notice Normal but significant. Routine events worth keeping, like a service starting or a configuration reload.
6 · Informational The ordinary running commentary: a request served, a scheduled job finished.
7 · Debug Verbose detail useful only when you are chasing a bug. "Debug" means detailed, not unimportant.

The other half of the number, the facility, says who is speaking: 0 is the kernel, 2 is the mail system, 3 is system daemons, 4 is authentication. The eight values from 16 to 23 are reserved as local0 through local7 for you to assign to your own applications, which is why so many home-grown services log as local0. Facilities are the least standardised part of syslog; the severities above are the part everyone agrees on.

The anatomy of one line

One line, nine fields, in a fixed order. The header runs up to the structured data, then the optional key=“value” block, then the human-readable message. The timestamp is a strict profile of RFC 3339 , the field that most sets RFC 5424 apart from the old format.

<165>PRI1VERSION2003-10-11T22:14:15.003ZTIMESTAMP · RFC 3339host.example.comHOSTNAMEevntslogAPP-NAME8710PROCIDID47MSGID[exampleSDID@32473 iut=“3”]STRUCTURED-DATAAn application event log entryMESSAGE
The same event in the old RFC 3164 dialect would read <165>Oct 11 22:14:15 host evntslog: An application event…: same priority number, but a timestamp with no year and no timezone, and no structured data at all.

5424 versus 3164, field by field

The clearest way to see what RFC 5424 fixed is to lay it next to the format it replaced. The timestamp is the headline change.

What changed From 3164 to 5424
Timestamp Old: Oct 11 22:14:15, no year, no timezone, whole seconds. New: a strict RFC 3339 timestamp with year, offset and sub-second precision. The single best reason to upgrade.
Header fields Old: one loose tag: glued to the message. New: separate, named fields for version, hostname, app-name, process ID and message ID.
Machine data Old: none, everything was free-form text. New: an optional structured-data block of key="value" pairs that tools can read without guessing.
Encoding Old: ASCII by custom, never actually pinned down. New: UTF-8, with a byte-order mark that announces it explicitly.
Standing Old: RFC 3164 was Informational, a description of what people already did. New: RFC 5424 is a Proposed Standard, a specification to build to.

What the RFC actually says

The original is about 30 pages, and denser than 1918, but the map is short. Where to look if you go to the source:

Section In plain words
1–5 · Intro & terms Why the old format fell short, and the vocabulary: facility, severity, and the parts of a message.
6 · Message format The heart of it: the PRI, the version, and every header field in fixed order. If you read one section, read this.
6.2.1 · PRI The angle-bracket number and the facility × 8 + severity formula, spelled out.
6.3 · Structured data How the [id key="value"] blocks are built, and why IDs carry an @enterprise number so nobody's field names clash.
8 · Security The honest part: syslog by itself has no authentication and no delivery guarantee. That is what the transport companions are for.

Things people get wrong

  • "Syslog is the file /var/log/syslog."

    No. Syslog is a message format and a protocol, not a file. /var/log/syslog is just one place one daemon on one Linux distribution happens to write. The same messages travel over the network, land in journald, get shipped to a SIEM, or never touch a file at all. RFC 5424 defines the line, not the destination.

  • "Port 514 is defined in RFC 5424."

    It is not. RFC 5424 defines only the message format and deliberately says nothing about transport. Plain UDP on port 514 comes from RFC 5426, and syslog over TLS on port 6514 from RFC 5425. Confusing the format with its transport is the single most common syslog misunderstanding.

  • "RFC 3164 was the syslog standard."

    It never was. RFC 3164 is Informational, which in IETF terms means "here is what people already do", not "here is what you must do". It documented BSD syslog after the fact, in 2001, decades after the format took hold. RFC 5424 is the first actual standards-track syslog specification. The predecessor described; the successor prescribes.

  • "Severity debug means the message is unimportant."

    Debug means detailed, not trivial. Severity ranks how urgent a line is for an operator, and debug (7) sits at the bottom because it is noise during normal running. But when you are hunting a bug, those are often the only lines that matter. Low severity is about routine, not worthlessness.

Where you'll meet RFC 5424

You have almost certainly generated syslog today without touching a config file. A field guide:

Where you meet it What it is
rsyslog / syslog-ng The two daemons that collect and forward syslog on most Linux servers. Both speak the RFC 5424 format; rsyslog needs a template switched on to emit it.
docker --log-driver=syslog Docker's syslog log driver ships container output as syslog, with --log-opt syslog-format=rfc5424 to pick the modern format.
Kubernetes log shippers Node agents like Fluent Bit and Vector parse and re-emit syslog on the way to central storage.
Firewalls & switches Cisco, Fortinet, MikroTik and friends emit syslog for every event. Much of it is still 3164-flavoured, which is why parsers must handle both.
Your SIEM Splunk, Elastic and QRadar ingest syslog as a primary feed. Structured data is what lets them index real fields instead of grepping text.

Questions people actually ask

What are the syslog severity levels? +

Syslog defines eight severity levels, from most to least urgent: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debug. The lower the number, the more severe. They are the same eight values RFC 5424 inherited from decades of BSD syslog, and they form the second half of the priority number at the start of every line.

What is the difference between RFC 5424 and RFC 3164? +

RFC 3164 merely described the loose, de-facto BSD syslog format, including its imprecise timestamp with no year and no timezone. RFC 5424 is a proper redesign: an RFC 3339 timestamp with year, timezone and sub-second precision, plus structured data fields. New systems should use 5424, though many devices still emit the old 3164 format.

What is structured data in RFC 5424? +

An optional, machine-readable part of the message made of named parameters grouped under an ID, such as origin or metadata about the event. It lets tools parse specific values instead of scraping free-form text, without giving up the human-readable message.

What is the difference between port 514 and 6514? +

Port 514 over UDP is the classic, unencrypted syslog transport, defined in RFC 5426. Port 6514 is syslog over TLS, defined in RFC 5425, which adds encryption and reliable delivery. Neither port is defined in RFC 5424 itself, which covers only the message format. Use 6514 when the logs are sensitive or must not be lost.

Should syslog use TCP or UDP? +

UDP on port 514 is the traditional choice and is fine for high-volume, low-stakes logging where an occasional lost message does not matter. For logs you must not lose, or that cross untrusted networks, prefer TCP or syslog over TLS (RFC 5425, port 6514). RFC 5424 defines the message independently of transport, so you can switch without touching the format.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 5424 connects

What came before

  1. RFC 3164 Informational, from 2001, it only wrote down what BSD syslog already did. RFC 5424 obsoletes it, yet half the world still emits the 3164 dialect: the rare case where the retired predecessor never actually left.

Part of a guided cluster: The network operations RFCs, explained