Syslog Protocol

For a long time, there was no true standard that syslog messages had to follow. As mentioned, syslog originated from messages that were logged by the UNIX operating system. However, syslog has been treated just as a loose recommendation and was never rigorously specified as a standard. Consequently, over time, different variations of syslog message formats proliferated across different vendors and device types. For example, they differed on details such as the precise format that is used to represent time—mm-dd-yyyy, or dd:mm:yyyy, or yyyymmdd. Also, in some cases, messages contain additional extensions that are present in some formats but not in others; a popular example involves numbering of messages.

In light of this situation, the IETF is in the process of passing a particular version of syslog as a standard, which is simply called the syslog protocol. It might seem odd that one of the oldest management message formats around is also one of the most recent to get standardized. In some ways, it feels like hearing that a couple that you have known for many years and that has been living together for all this time without being married seemingly out of the blue decides to finally tie the knot. The IETF syslog protocol is just one of many syslog variations, but because this particular one has a good chance of becoming a dominant syslog format going forward, we use the current draft as an example to explore the different fields that a syslog message can contain.

According to this IETF syslog protocol, a syslog message consists of a header part, an optional structured data part, and a message part (see Figure 8-7).

Figure 8-7 syslog Message Structure According to IETF


Structured Data


Priority (facility*3+ severity)


Time stamp

Host name

App name


Message ID









The header part includes the following fields:

■ The priority is a combination of a facility and a severity. The facility allows categorization of a message according to some criteria (for example, kernel message) and is given a numeric code. The severity is a number from 0 to 7, with 0 being the most severe and 7 being the least severe. The priority is formed by multiplying the numeric code of the facility by 8 and adding the severity to it. For example, a syslog message with facility 7 and severity 3 has a priority of 59 (7 x 8 + 3). The reason for this apparently strange scheme has to do with backward compatibility of the syslog protocol with existing implementations.

■ The version number of the syslog protocol.

■ The time stamp, according to a well-defined format.

■ The host name, identifying the system from which the syslog message originates. The identifier should be the so-called fully qualified domain name, but other identifiers, such as the static IP address of the host, also can be used.

■ The application name and the process ID, which identify the subsystem and process that are responsible for emitting the message.

■ Finally, the message ID, an identifier of the type of syslog message.

The structured data part is optional but is perhaps the most interesting part of the protocol. It allows the syslog message format to be extensible to a certain degree and to carry additional parameters that are formally defined. This obviates the need to put the corresponding information into the body part of the message, which is still free format—anything goes.

Structured data is contained in a set of fields, called structured data elements (SDEs). SDEs are optional; there can be none, one, or several of them. Each SDE contains a label that identifies the SDE, followed by a set of name-value pairs (again, none, one, or several of them), each containing the name of a parameter and its corresponding value. The meaning of those parameters is specific to the structured data element.

By introducing proprietary structured data elements, anyone can define their own syslog protocol extensions. For example, a vendor might introduce an SDE that identifies the configuration version currently on the device at the time the syslog message is generated. If a recipient is familiar with the data element as defined by the label, it can interpret the data that it carries and take advantage of it. If not, the recipient can ignore it and should still be able to make sense of the rest of the message—it cannot take advantage of the added value provided by the SDE, but otherwise no harm is done.

Compare this with the scenario in which a product has a bar code printed on the box. The bar code contains certain information that makes perfect sense for its intended application but probably not to you, the consumer. However, you will still be able to understand the rest of what the package says.

Finally, the message part consists of the message itself. It is still free format and does not require, for example, an underlying formally defined management information model. Of course, vendors can follow their own proprietary conventions of what to put in the message, but basically, anything goes.

Here is an example of a syslog message that is IETF syslog protocol compliant:

<35>1 2006-06-11T22:14:15.003Z su - ID58 - 'su root' failed for wbuchhau on /dev/pts/8

The facility of the message has a value of 4; the severity is 3 (because 35 = 4 x 8 + 3). The version of the syslog protocol is 1. The message was created on 11 June 2006 at 10:14:15pm UTC (in essence, Greenwich Mean Time), 3 milliseconds into the next second. The message originated from a host that identifies itself as, from an application or subsystem named su. The process ID is unknown; the identifier of the type of message is ID58. There is no structured data, as indicated by the - in the Structured Data field. Finally, the message itself is "'su root' failed for wbuchhau...".

The final example is taken from the specification and includes some structured data. The structured data element is called [email protected], and it includes three parameters, called iut, eventSource, and eventID.

<165>1 2003-10-11T22:14:15.003Z evntslog - ID47 [[email protected] iut="3" eventSource="Application" eventID="1011"] An application event log entry...

0 0

Post a comment