In a previous post, I wrote about using SNMP traps to get status information from the devices on your network. Traps are great because they don't require any active polling on your part: you configure your devices to send a trap to your network monitoring application when any of a number of fault conditions arises, and you know almost instantaneously when something has gone awry.

 

Easy network monitoring. Sweet. But traps aren't the only game in town. Let's talk syslog.

 

What is Syslog?

Without going too deeply into the History of the Internet, syslog started as a Unix-based, status messaging format. Over time, it has been widely adopted by a variety of device types for status communications. Like SNMP traps, syslog messages originate at the device. Syslog is also largely OS-agnostic, so it is relatively easily implemented. If a device is on your network, it is probably syslog-capable.

 

What does Syslog communicate?

In its most basic, standard form, as presented in RFC 5424, syslog communicates device status in a packet of information, the most useful piece of which is the syslog priority. The priority value is calculated from a combination of any of 8 defined status types, or severities, for any of 24 types of network messages, or facilities. Eight of the 24 facilities are completely open to be defined locally to the syslog-capable device. The rest do have default values that can, however, be used as you see fit for your network and devices. Any syslog-capable network element is able to send a message consisting of a facility and a severity. With 24 facilities, each capable of reporting 8 severities, syslog provides 192 unique messages, some custom and some pre-defined, for network monitoring. Each of these unique facility and severity combinations is encoded as a syslog priority.

 

So, what exactly are syslog facilites, severities, and priorities? That is an excellent question.

 

What is a syslog facility?

According to RFC 5424, syslog facilities are defined as follows:

              

Numerical CodeFacility
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 (note 2)
16local use 0  (local0)
17local use 1  (local1)
18local use 2  (local2)
19local use 3  (local3)
20local use 4  (local4)
21local use 5  (local5)
22local use 6  (local6)
23local use 7  (local7)

 

Facilities 16 through 23 may be mapped to local properties of the device sending the syslog message.

 

What is a syslog severity?

RFC 5424 has formalized potential states for network elements as follows:

              

Numerical CodeSeverity
0Emergency: system is unusable
1Alert: action must be taken immediately
2Critical: critical conditions
3Error: error conditions
4Warning: warning conditions
5Notice: normal but significant condition
6Informational: informational messages
7Debug: debug-level messages

              

Notice the slight but important differences among the different severities. These can, of course, be translated in your own way in your own IT environment. In other words, your network may not be large enough to require the differentiation of issues into Alert, Critical, and Error; you might just think of them all as 'broken'. That's OK. Syslog can go with that.

              

Putting it all together with syslog priority

Syslog priority is a calculated value that is simply defined as follows:

  Priority = (8 x Facility) + Severity

This formula gives you 192 distinct messages, each communicating a status for a specific component or element of a monitored device. For example, if a device sends a syslog message with a priority of 35 you know the device is experiencing an authorization error, as 35 = 8 x Facility(4) + Severity(3). This priority value, with the other basic system info in the syslog packet, gives you an instant reading of device status, delivered when the device needs it delivered.

 

Getting the message

As soon as you get syslog set up on a monitored device, point the syslog sender on that device to either a syslog-capable log reader or a network management platform to parse the messages your devices are sending. For more information about what SolarWinds Orion applications can do with syslog messages, see "Monitoring Syslog Messages" in the SolarWinds Orion NPM Administrator Guide.

Syslog is a pretty simple massaging format, and it is also fairly flexible. There is a lot you can communicate in a syslog packet. For more information about syslog, as a technology, see RFC 5424.