Understand syslog message fields: PRI, timestamp, and tag

Read RFC 3164 and RFC 5424 messages, decode facility and severity, and recognize timestamp and whole-message size limits.

Best practices
Illustration of log collection and monitoring

A traditional syslog message combines a priority value, a header, and a message body. Start with this example:

<34>Oct 11 22:14:15 myhost su: 'su root' failed for lonvick on /dev/pts/8

<34> is the priority, Oct 11 22:14:15 is the timestamp, myhost identifies the host, and su: introduces the application's message.

Decode the RFC 3164 fields

Field Meaning in this example
PRI 34 = 4 × 8 + 2: facility 4, security/authorization, and severity 2, critical
Timestamp Local month, day, and time; no year or time-zone offset
Hostname myhost, the reported source host
Tag su, the program identifier; implementations often include a PID after it
Content The application's text describing the failed operation

The priority calculation is facility × 8 + severity. Common facilities include kernel (0), user (1), daemon (3), security/authorization (4), and local0 through local7 (16–23). Lower severity numbers indicate more urgent events: emergency is 0, critical is 2, and debug is 7.

RFC 3164's 1,024-byte limit applies to the entire message, including the header, not just the application's text. Many implementations accept larger messages, so distinguish the documented legacy format from the limits configured on your actual pipeline.

Read an RFC 5424 message

<34>1 2024-01-15T10:30:00.123Z myhost app 1234 ID47 [exampleSDID@32473 k="v"] Request failed

The fields after PRI are version, timestamp, hostname, application name, process ID, message ID, structured data, and the optional message text. Here the version is 1; the timestamp includes a year, fractional seconds, and Z for UTC. The bracketed section holds structured metadata. A hyphen can represent a missing value in fields where the format permits it.

Prefer RFC 5424 when senders and receivers support it and you need unambiguous timestamps or structured metadata. Selecting a format does not by itself choose UDP, TCP, TLS, or a framing method; configure the transport at both ends too.

FAQ

How does a receiver supply a missing year?

A receiver may infer it from its own clock and parsing rules. That inference can be wrong for delayed delivery, archived files, or events near New Year. Preserve the original text when importing historical RFC 3164 logs, and inspect the assigned timestamp before relying on time-based queries.

Is the host field proof of the sender's identity?

No. It is a field in the message. A relay may preserve it, and an untrusted sender may forge it. Use transport metadata and authenticated connections when identifying the source matters.

References: RFC 3164 and RFC 5424.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting