Syslog Message Format Explained: RFC 3164 vs RFC 5424, PRI, Facility and Severity

Syslog messages may initially look like long strings of timestamps, numbers, hostnames, application names, and device-specific text.

Once the message structure is understood, however, Syslog becomes much easier to troubleshoot and analyze.

A Syslog message can contain information such as:

• Event severity
• Logging facility
• Timestamp
• Source hostname
• Application
• Process identifier
• Event identifier
• Structured metadata
• Human-readable event details

Two formats are especially important:

• RFC 3164-style legacy Syslog
• RFC 5424 modern Syslog

Network vendors may also place their own proprietary information inside the message payload.

For example:

• Cisco IOS uses facility-severity-mnemonic messages.
• FortiGate commonly uses key-value fields.
• Linux services frequently use application and process identifiers.
• Windows events may be converted into Syslog by an agent or collector.

Understanding which portion belongs to the Syslog protocol and which portion belongs to the vendor is essential when building:

• SIEM parsers
• Log filters
• Security detections
• Troubleshooting workflows

Understanding RFC 3164 and RFC 5424 Syslog Formats

There is no single visual appearance shared by every Syslog message.

The actual format depends on:

• Syslog specification
• Device
• Operating system
• Application
• Vendor
• Logging configuration
• Collector processing

RFC 3164-Style Syslog

RFC 3164 documents the traditional BSD Syslog format commonly found on older Unix systems and many network devices.

A typical message may resemble:

Jul 15 10:22:33 web01 sshd[12345]: Accepted publickey for user from 192.0.2.25

The message can be interpreted as:

TIMESTAMP HOSTNAME TAG: CONTENT

The main components are:

• PRI
• Timestamp
• Hostname
• TAG
• Message content

RFC 3164 is relatively loose compared with RFC 5424.

This is one reason collectors often require vendor-specific parsers for legacy messages.

RFC 5424 Syslog

RFC 5424 introduced a much more clearly defined structure.

The formal high-level format is:

VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA [MSG]

Example:

1 2026-07-15T10:22:33.123Z web01.example.com sshd 12345 LOGIN [auth@32473 method="publickey" src="192.0.2.25"] User authenticated successfully

The fields are:

RFC 5424 uses:

1

as the protocol VERSION defined by that specification.

NILVALUE

RFC 5424 uses:

-

when a field has no value.

For example:

1 2026-07-15T10:22:33Z router01.example.com bgpd - NEIGHBOR - BGP neighbor down

Here:

• PROCID is unavailable.
• STRUCTURED-DATA is unavailable.

Both can use the NILVALUE:

-

How PRI, Facility and Severity Work

The first field in a Syslog message is:

PRI

or:

Priority

Example:

PRI is not simply the severity.

It contains both:

• Facility
• Severity

PRI Formula

The formula is:

PRI = (Facility × 8) + Severity

Consider:

• Facility = Local0 = 16
• Severity = Informational = 6

Then:

PRI = (16 × 8) + 6

PRI = 128 + 6

PRI = 134

Therefore:

means:

Local0 + Informational

Decode PRI Manually

Given:

Facility:

134 / 8 = 16 remainder 6

Therefore:

• Facility = 16
• Severity = 6

Severity Levels

Syslog severity values range from:

0 to 7

A lower numeric value represents a more severe event.

Facility Codes

Facility identifies the category associated with the message.

Facilities local0 through local7 are often used by network devices and applications that need administrator-defined categories.

Breaking Down an RFC 5424 Message

Consider this complete message:

1 2026-07-15T10:22:33.123+05:30 fw01.example.com firewall 4821 AUTH [login@32473 user="admin" src="192.0.2.25" result="success"] Administrator login completed

PRI

This represents:

• Local0
• Informational

VERSION

1

This identifies the RFC 5424 protocol version.

TIMESTAMP

2026-07-15T10:22:33.123+05:30

RFC 5424 timestamps are derived from RFC 3339 formatting.

This example provides:

• Date
• Time
• Millisecond precision
• UTC offset

This is significantly more precise than many traditional RFC 3164-style timestamps.

HOSTNAME

fw01.example.com

RFC 5424 recommends using the most specific useful source identity available, preferably an FQDN when possible.

APP-NAME

firewall

APP-NAME identifies the application or subsystem that originated the message.

PROCID

4821

PROCID can identify a:

• Process ID
• Transaction
• Restart identifier
• Implementation-defined process context

It is not required to be an operating-system PID in every implementation.

MSGID

AUTH

MSGID identifies the type of event.

A vendor might define values such as:

• AUTH
• LINK_DOWN
• CONFIG_CHANGE
• VPN_LOGIN
• TCPIN

STRUCTURED-DATA

[login@32473 user="admin" src="192.0.2.25" result="success"]

Structured data consists of:

• SD-ID
• Parameter names
• Parameter values

The example contains:

• user
• src
• result

Structured data is particularly useful for:

• SIEM ingestion
• Automated parsing
• Filtering
• Correlation
• Analytics

MSG

Administrator login completed

MSG contains the application-specific message content.

Interestingly, RFC 5424 allows a valid message to contain structured data without a human-readable MSG at all.

Linux, Cisco, FortiGate and Windows Syslog Examples

A common mistake is assuming that every vendor will display exactly the RFC 5424 fields in the same visual format.

In practice, vendor payloads vary significantly.

Linux Example

A traditional Linux SSH event might resemble:

Jul 15 10:22:33 web01 sshd[12345]: Accepted publickey for user from 192.0.2.25 port 55214 ssh2

Breaking it down:

This is closer to traditional BSD-style formatting than a strict RFC 5424 message.

Cisco IOS Example

Cisco IOS system messages commonly contain:

%FACILITY-SEVERITY-MNEMONIC: message-text

Example:

%LINK-5-CHANGED: Interface GigabitEthernet1/0/1, changed state to administratively down

Cisco documents this as:

%--:

A message may also include:

• Sequence number
• Timestamp

Example:

000013: Jul 15 10:22:33.039: %LINK-5-CHANGED: Interface GigabitEthernet1/0/1, changed state to administratively down

Here:

• LINK is Cisco’s message facility/subsystem.
• 5 represents Notice severity.
• CHANGED is the message mnemonic.

FortiGate Example

FortiGate raw logs commonly use key-value fields.

A shortened example is:

date=2026-07-15 time=10:22:33 logid="0100032001" type="event" subtype="system" level="notice" devname="FGT-BRANCH01" srcip=192.0.2.25 user="admin" action="login" status="success"

Important fields may include:

• date
• time
• logid
• type
• subtype
• level
• devname
• srcip
• user
• action
• status

FortiOS uses extensive vendor-defined fields in its raw log payload.

A Syslog collector therefore needs a FortiGate-aware parser if it wants to extract these values into dedicated SIEM fields.

Windows Event Logs Sent Through Syslog

Windows does not natively format every Windows Event Log record as an RFC 5424 Syslog message.

Agents or collectors may convert events into Syslog.

Possible products or methods include:

• NXLog
• SIEM agents
• Windows event collectors
• Third-party forwarders

A converted message may contain fields such as:

• Event ID
• Channel
• Provider
• Account
• Computer
• Logon type

The final Syslog representation depends on the forwarding tool’s configuration.

Therefore, there is no single universal:

Windows Syslog format

Application Logs

Applications may also use Syslog as the delivery mechanism while keeping their own payload syntax.

For example:

Jul 15 10:22:33 web01 nginx: client=192.0.2.25 status=200 method=GET uri="/login"

The Syslog envelope identifies the source.

The application determines the content inside the message.

Parsing, Normalization and Common Syslog Problems

Understanding format differences becomes especially important when feeding Syslog into:

• Splunk
• Microsoft Sentinel
• Elastic
• QRadar
• Wazuh
• Other SIEM systems

Parsing

Parsing separates raw text into meaningful fields.

For example:

srcip=192.0.2.25
dstip=198.51.100.10
action=deny

may become:

Normalization

Normalization maps different vendor field names into a common schema.

For example:

Cisco: src
FortiGate: srcip
Vendor X: source_address

A SIEM might normalize them all as:

source.ip

This allows one security rule to operate across multiple vendors.

RFC 5424 Parsing

Modern logging systems such as rsyslog include RFC 5424-aware parsers.

RFC 5424 is easier to process consistently because important metadata has explicit fields.

Legacy Parsing

RFC 3164-style messages often require more inference.

Different vendors may modify:

• Timestamp placement
• TAG syntax
• Hostname
• Message body

This makes legacy parsing more fragile.

Timestamp Problems

One of the most common problems in logging is inconsistent time.

For example:

Jul 15 10:22:33

does not explicitly contain:

• Year
• Time zone

while:

2026-07-15T10:22:33.123+05:30

does.

Accurate timestamps are essential for:

• Incident reconstruction
• Event correlation
• Authentication analysis
• Troubleshooting

Wrong PRI Interpretation

A parser that treats PRI as only severity will produce incorrect results.

Remember:

PRI = Facility × 8 + Severity

Wrong Vendor Parser

If a FortiGate message is parsed using a generic Linux parser, fields such as:

• srcip
• policyid
• action
• logid

may remain buried inside raw text.

Always use the correct vendor parser where possible.

Message Truncation

Large messages can be truncated because of:

• Sender limits
• Receiver limits
• Transport configuration
• Collector settings

If important fields disappear near the end of messages, compare:

• Raw packet
• Collector raw event
• SIEM event

to determine where truncation occurs.

Parser Troubleshooting Workflow

Key Takeaways and Summary

Key Takeaways

1. Syslog message formatting varies between legacy, modern, and vendor-specific implementations.
2. RFC 3164 describes the traditional BSD-style Syslog format.
3. RFC 5424 defines the modern standardized Syslog message format.
4. RFC 5424 messages contain PRI, VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID, STRUCTURED-DATA and optional MSG.
5. PRI combines facility and severity.
6. The formula is PRI = Facility × 8 + Severity.
7. Kernel is facility 0; user-level messages are facility 1.
8. Severity ranges from 0 Emergency through 7 Debug.
9. RFC 5424 structured data provides machine-readable parameter/value metadata.
10. RFC 5424 supports more precise timestamps and explicit metadata than traditional RFC 3164-style messages.
11. Cisco commonly uses %FACILITY-SEVERITY-MNEMONIC inside its vendor-specific message content.
12. FortiGate commonly uses extensive key-value fields in its raw log payload.
13. Windows Event Logs require an agent or integration when being converted to Syslog.
14. Syslog transport and Syslog message format are separate concepts.
15. UDP versus TCP does not inherently determine whether the message is RFC 3164 or RFC 5424.
16. Reliable SIEM ingestion requires correct parsing and normalization for each log source.

Summary

Understanding Syslog message format is essential for anyone working with:

• Network monitoring
• SIEM
• Firewalls
• Linux servers
• Routers
• Switches
• Security analytics

The most important distinction is between:

Syslog protocol fields

and:

Vendor-specific message content

RFC 5424 defines the modern message structure as:

VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA [MSG]

The PRI value combines:

Facility + Severity

while structured data allows applications to carry machine-readable metadata.

Legacy RFC 3164 messages remain widespread, particularly on network infrastructure, but their looser structure makes parsing more dependent on vendor-specific logic.

The best approach when analyzing an unfamiliar Syslog message is:

1. Identify whether it resembles RFC 5424 or legacy Syslog.
2. Decode PRI.
3. Identify the timestamp and hostname.
4. Identify the application or subsystem.
5. Separate the Syslog envelope from vendor-specific content.
6. Parse vendor fields.
7. Normalize fields for SIEM or analytics.

Understanding this process makes raw Syslog events much easier to read, troubleshoot, and transform into useful operational and security information.

Useful Links and References

SanchitGurukul Static Resources

Related SanchitGurukul Articles

Official External References