The Syslog Protocol
- Omry Koschitzky
Syslog Facilities
The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of Unix processes and Daemons. The priority value is calculated using the following formula: Priority = Facility * 8 + Level
The list of Facilities available:
0 Â Â Â Â Â Â kernel messages
1 Â Â Â Â Â Â user-level messages
2 Â Â Â Â Â Â mail system
3 Â Â Â Â Â Â system daemons
4 Â Â Â Â Â Â security/authorization messages
5 Â Â Â Â Â Â messages generated internally by syslogd
6 Â Â Â Â Â Â line printer subsystem
7 Â Â Â Â Â Â network news subsystem
8 Â Â Â Â Â Â UUCP subsystem
9 Â Â Â Â Â Â clock daemon
10 Â Â Â Â Â Â security/authorization messages
11 Â Â Â Â Â Â FTP daemon
12 Â Â Â Â Â Â NTP subsystem
13 Â Â Â Â Â Â log audit
14 Â Â Â Â Â Â log alert
15 Â Â Â Â Â Â clock daemon
16 Â Â Â Â Â Â local use 0 Â (local0)
17 Â Â Â Â Â Â local use 1 Â (local1)
18 Â Â Â Â Â Â local use 2 Â (local2)
19 Â Â Â Â Â Â local use 3 Â (local3)
20 Â Â Â Â Â Â local use 4 Â (local4)
21 Â Â Â Â Â Â local use 5 Â (local5)
22 Â Â Â Â Â Â local use 6 Â (local6)
23 Â Â Â Â Â Â local use 7 Â (local7)
If you are receiving messages from a Unix system, it is recommended to use the 'User' Facility as your first choice. Local0 through to Local7 are not used by Unix and are traditionally used by networking equipment. Cisco routers for example use Local6 or Local7.
Syslog Levels
The list of severity Levels:
0 Â Â Â Emergency: system is unusable
1 Â Â Â Alert: action must be taken immediately
2 Â Â Â Critical: critical conditions
3 Â Â Â Error: error conditions
4 Â Â Â Warning: warning conditions
5 Â Â Â Notice: normal but significant condition
6 Â Â Â Informational: informational messages
7 Â Â Â Debug: debug-level messages
Recommended practice is to use the Notice or Informational level for normal messages.
Severity Levels Details:
DEBUG:Â Info useful to developers for debugging the app, not useful during operations
INFORMATIONAL:Â Normal operational messages - may be harvested for reporting, measuring throughput, etc - no action required
NOTICE:Â Events that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required
WARNING:Â Warning messages - not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given timeÂ
ERROR:Â Non-urgent failures - these should be relayed to developers or admins; each item must be resolved within a given time
ALERT:Â Should be corrected immediately - notify staff who can fix the problem - example is loss of backup ISP connection
CRITICAL:Â Should be corrected immediately, but indicates failure in a primary system - fix CRITICAL problems before ALERT - example is loss of primary ISP connection
EMERGENCY:Â A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call.
Syslog Priority values
The PRI part is a number that is enclosed in angle brackets. This represents both the Facility and Severity of the message. This number is an eight bit number. The first 3 least significant bits represent the Severity of the message (with 3 bits you can represent 8 different Severities) and the other 5 bits represent the Facility of the message. You can use the Facility and the Severity values to apply certain filters on the events in the Syslog Daemon. Note that Syslog Daemon cannot generate these Priority and Facility values. They are generated by the applications on which the event is generated. Following are the codes for Severity and Facility. Please note that the codes written below are the recommended codes that the applications should generate in the specified situations. You cannot, however, be 100 % sure if it really is the correct code sent by the application. For example: An application can generate a numerical code for severity as 0 (Emergency) when it should have generated 4 (Warning) instead. Syslog Daemon can not do anything about it!! It will simply receive the message as it is.
Calculating Priority Value
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a Syslog message, these values would be placed between the angle brackets as <0> and <165> respectively.
Syslog Header
The HEADER part contains the following things:
Timestamp -- The Time stamp is the date and time at which the message was generated. Be warned, that this timestamp is picked up from the system time and if the system time is not correct, you might get a packet with totally incorrect time stamp
Hostname or IP address of the device.
Syslog Message
The MSG part will fill the remainder of the Syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. The MSG part has two fields:
TAG field
CONTENT field
The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message.