Skip to main content

6. Syslog Message Format

The syslog message has the following ABNF definition:

SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]

HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME
                  SP APP-NAME SP PROCID SP MSGID
PRI             = "<" PRIVAL ">"
PRIVAL          = 1*3DIGIT ; range 0 .. 191
VERSION         = NONZERO-DIGIT 0*2DIGIT
HOSTNAME        = NILVALUE / 1*255PRINTUSASCII

APP-NAME        = NILVALUE / 1*48PRINTUSASCII
PROCID          = NILVALUE / 1*128PRINTUSASCII
MSGID           = NILVALUE / 1*32PRINTUSASCII

TIMESTAMP       = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE       = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR   = 4DIGIT
DATE-MONTH      = 2DIGIT  ; 01-12
DATE-MDAY       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
FULL-TIME       = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME    = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
                  [TIME-SECFRAC]
TIME-HOUR       = 2DIGIT  ; 00-23
TIME-MINUTE     = 2DIGIT  ; 00-59
TIME-SECOND     = 2DIGIT  ; 00-59
TIME-SECFRAC    = "." 1*6DIGIT
TIME-OFFSET     = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET  = ("+" / "-") TIME-HOUR ":" TIME-MINUTE

STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT      = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID           = SD-NAME
PARAM-NAME      = SD-NAME
PARAM-VALUE     = UTF-8-STRING
SD-NAME         = 1*32PRINTUSASCII

MSG             = MSG-ANY / MSG-UTF8
MSG-ANY         = *OCTET
MSG-UTF8        = BOM UTF-8-STRING
BOM             = %xEF.BB.BF
UTF-8-STRING    = *OCTET

OCTET           = %d00-255
SP              = %d32
PRINTUSASCII    = %d33-126
NONZERO-DIGIT   = %d49-57
DIGIT           = %d48 / NONZERO-DIGIT
NILVALUE        = "-"

The message consists of:

  • HEADER: Contains metadata about the message (priority, version, timestamp, source information)
  • STRUCTURED-DATA: Optional structured information in name-value pairs
  • MSG: Optional free-form message content

6.1. Message Length​

Syslog messages MUST NOT exceed 480 octets for UDP transport. This ensures compatibility with limited network implementations.

Syslog receivers MUST be able to accept messages of up to 480 octets. Receivers SHOULD be able to accept messages of up to 2048 octets.

Syslog senders MAY send messages longer than 480 octets. However, they SHOULD implement message truncation or splitting mechanisms if needed.

Transport mappings MAY specify different maximum message sizes. For example, TLS transport typically allows much larger messages.

The message length is measured in octets, not characters. UTF-8 encoding may result in multiple octets per character.

6.2. HEADER​

The HEADER contains the following fields in this exact order:

6.2.1. PRI​

The PRI part contains the Priority value enclosed in angle brackets. The Priority value is calculated from the Facility and Severity values:

Priority = Facility * 8 + Severity

Facility values:

ValueFacility
0kernel messages
1user-level messages
2mail system
3system daemons
4security/authorization messages
5messages generated internally by syslogd
6line printer subsystem
7network news subsystem
8UUCP subsystem
9clock daemon
10security/authorization messages
11FTP daemon
12NTP subsystem
13log audit
14log alert
15clock daemon
16-23local use 0-7 (local0 - local7)

Severity values:

ValueSeverityDescription
0EmergencySystem is unusable
1AlertAction must be taken immediately
2CriticalCritical conditions
3ErrorError conditions
4WarningWarning conditions
5NoticeNormal but significant condition
6InformationalInformational messages
7DebugDebug-level messages

Example: A message with Facility 4 (security/authorization) and Severity 2 (Critical) has Priority value:

Priority = 4 * 8 + 2 = 34
PRI = "<34>"

The PRI value MUST be between 0 and 191.

6.2.2. VERSION​

The VERSION field denotes the version of the syslog protocol. This document defines version 1. The VERSION value MUST be a non-zero integer in the range 1-999.

6.2.3. TIMESTAMP​

The TIMESTAMP field is a formatted timestamp indicating when the message was generated. It SHOULD represent the time when the event being described occurred.

The timestamp format is based on RFC 3339 with the following requirements:

  • Date in YYYY-MM-DD format
  • Time separator "T"
  • Time in HH:MM:SS format (24-hour)
  • Optional fractional seconds (up to 6 digits)
  • Time zone offset (either "Z" for UTC or "+/-HH:MM")

Examples:

2003-10-11T22:14:15.003Z
2003-08-24T05:14:15.000003-07:00
2009-03-12T18:53:01+00:00

If the originator does not know the time, it MUST use the NILVALUE ("-").

Best practices:

  • Use UTC time zone (Z) when possible for consistency
  • Include fractional seconds when precision is important
  • Ensure time synchronization (NTP) for accurate timestamps

6.2.4. HOSTNAME​

The HOSTNAME field identifies the machine that originally generated the syslog message. It SHOULD contain one of the following:

  1. Fully Qualified Domain Name (FQDN) - RECOMMENDED
  2. Static IP address
  3. Hostname
  4. Dynamic IP address
  5. NILVALUE ("-") if unknown

The FQDN is the RECOMMENDED format as it provides the most accurate identification.

If an IPv6 address is used, it SHOULD be enclosed in square brackets.

Maximum length: 255 ASCII printable characters.

6.2.5. APP-NAME​

The APP-NAME field identifies the device or application that generated the message. It is a free-form string with no spaces.

Examples:

myapp
su
postfix/smtpd

Maximum length: 48 ASCII printable characters.

If the APP-NAME is unknown, use the NILVALUE ("-").

6.2.6. PROCID​

The PROCID field is a value that changes every time a process is started or restarted. It typically contains:

  • Process ID (PID) on Unix-like systems
  • Thread ID
  • Process name
  • Other unique identifier

Examples:

12345
thread1
-

Maximum length: 128 ASCII printable characters.

If PROCID is not used, set to NILVALUE ("-").

6.2.7. MSGID​

The MSGID field identifies the type of message. It is a free-form string without spaces that can be used for automated parsing and routing.

Examples:

ID47
TCPIN
login-failure
config-change

Maximum length: 32 ASCII printable characters.

If MSGID is not used, set to NILVALUE ("-").

6.3. STRUCTURED-DATA​

STRUCTURED-DATA provides a mechanism to express information in a structured, easily parseable format. It consists of one or more SD-ELEMENTs.

6.3.1. SD-ELEMENT​

An SD-ELEMENT consists of:

  • SD-ID (identifier)
  • Zero or more SD-PARAMs (parameters)

Format: [SD-ID PARAM1="value1" PARAM2="value2" ...]

6.3.2. SD-ID​

The SD-ID uniquely identifies the type and purpose of the element.

IANA-registered SD-IDs: Consist of printable ASCII characters excluding =, ], ", and space.

Private Enterprise SD-IDs: Must be of the format name@<private enterprise number> where the enterprise number is registered with IANA.

Examples:

timeQuality
origin
myCompany@32473

6.3.3. SD-PARAM​

Each SD-PARAM is a name-value pair:

PARAM-NAME="PARAM-VALUE"

The PARAM-VALUE MUST be encoded using UTF-8. Special characters must be escaped:

  • " becomes \"
  • \ becomes \\
  • ] becomes \]

Example:

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Multiple values for the same parameter name are allowed by repeating the parameter:

[example ip="192.0.2.1" ip="192.0.2.2"]

6.3.4. Change Control​

New SD-IDs can be registered through IANA. See Section 9 for details.

Private enterprises can use their registered enterprise number to create private SD-IDs without registration.

6.3.5. Examples​

Single SD-ELEMENT:

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Multiple SD-ELEMENTs:

[exampleSDID@32473 iut="3"][examplePriority@32473 class="high"]

No structured data:

-

6.4. MSG​

The MSG part contains the free-form message text. It has two possible formats:

  1. MSG-ANY: Any sequence of octets
  2. MSG-UTF8: UTF-8 string prefixed with BOM (Byte Order Mark: 0xEF 0xBB 0xBF)

If the MSG begins with the UTF-8 BOM, the collector or relay SHOULD assume the MSG is encoded in UTF-8. Otherwise, the encoding is unspecified.

The MSG part is optional. If absent, no SP precedes the end of the message.

Best practices:

  • Use UTF-8 encoding with BOM for consistent international character support
  • Avoid including newlines or other control characters
  • Keep important information early in the message (within first 480 octets)

6.5. Examples​

Example 1: Full message with all fields and structured data

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMsystem crashed

Example 2: Message with NILVALUE fields

<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.

Example 3: Message with UTF-8 content and multiple SD-ELEMENTs

<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"] BOMAn application event log entry...

Example 4: Minimal message (emergency kernel message)

<0>1 2009-03-12T18:53:01+00:00 server1 kernel - - - System will shutdown
Last updated on