Net/Systems Management /

As easy as falling off a syslog

By Mark Gibbs
Network World, 06/10/02

There are many devices out there in network land that want to tell you how they are. And they usually want to tell you because they don't have enough storage to wait for you to ask. We're talking the likes of routers, firewalls and switches.

The service these devices use for reporting is called syslog, which along with SNMP traps, logging to a local text file and console logging, are the four main ways of reporting conditions and exceptions. Actually the syslog service can be used by any process - there are tools to syslog-enable Windows NT, for example.

Syslog is a relatively old protocol that was first documented as an Internet Engineering Task Force request for comments in 2001. This document, RFC 3164 is titled "The BSD syslog Protocol" and the RFC explains:

"This protocol has been used for the transmission of event-notification messages across networks for many years. While this protocol was originally developed on the University of California Berkeley Software Distribution TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices."

The architecture of a syslog logging system consists of machines generating messages that are called "devices" (or "senders") and machines that receive the messages called "collectors," more commonly (and incorrectly) called "syslog server" (they actually act as clients to which the devices "push" messages).

A syslog system also can include machines that receive device messages and forward them to other machines. These are called "relays," and there can be any number of them chained between a device and the final collector.

Some devices can send syslog messages to multiple collectors, and relays might also filter messages so for example, only critical messages are forwarded. In this case the relay also acts as a collector and, like a device, might relay to multiple collectors.

Syslog messages usually are transported by User Datagram Protocol (UDP), although some devices and collectors can use TCP for reliable messaging (remember that UDP is only a "best effort" service). The port assigned to syslog is 514, and it is recommended that the source port also be 514 to indicate that the message is from the syslog process of the sender.

A syslog message has three parts: The first is called the PRI; the second the HEADER; and the third, the MSG. The total length of the packet cannot exceed 1,024 bytes, and there is no minimum length.

The PRI part indicates the priority of the syslog message and consists of one to three characters, enclosed in angle brackets, for example: "<1>", "<23>" and "<203>" are valid PRI contents. The PRI code is formed from two values: a facility code and a severity code.

There are standard facility codes, for example "0" is for kernel messages (gotta love *nix), "1" for user-level messages, "2" for mail system messages and so on.

There also are severity codes: "0" is for "Emergency: system is unusable," "1" is for "Alert: action must be taken immediately" and so on (see RFC 3164).

The actual PRI code is derived by multiplying the facility code value by eight (that is, a three-bit left shift) and adding the severity code value. The only time the PRI code should start with "0" is if the PRI part is "<0>" (for example facility and severity are both zero).

The HEADER consists of two fields: the TIMESTAMP and the HOSTNAME. The TIMESTAMP (formatted as "Mmm dd hh:mm:ss") immediately follows the trailing ">" of the PRI part and a single space character follows the TIMESTAMP and HOSTNAME fields. HOSTNAME should contain the hostname or if that isn't available, the device's IP address.

The MSG part is what you might guess - a text message that explains or clarifies the PRI code. It has two subparts: a TAG of up to 32 characters that names the program generating the syslog message, and CONTENT that contains the actual text.

Any nonalphanumeric character is considered to terminate the TAG field and is assumed to be the starting character of the CONTENT field.

Typically this character has been a left square bracket character ("['), a colon character (":") or a space character.

So from RFC 3164, here's an example of a valid syslog message:

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

Next week, more theory and a killer syslog collector.

Your status to gearhead@gibbs.com.