Facilities and severities
The syslog facility and severity codes are used with the sendlog program and within the CO-logmon.cnf configuration file. For more information about the syslog protocol, as well as more information on the various facilities and severities, see Syslog protocol in the "BMC AMI Command Center for Security" space. The following information is a quick reference.
Syslog facility codes and their meaning
The basic facilities, defined by RFC 3164, are discussed as follows:
Facility | Code | Description |
|---|---|---|
Kernel | 0 | These are messages related to the Unix kernel process, or generated by very low-level driver software and system programs. |
User | 1 | These are typically user-defined messages. This facility is used (and over-used) as a central way of defining messages that have not been otherwise classified. |
2 | These are messages related to the SMTP system, Microsoft Exchange, as well as mail relay systems, and sometimes e-mail programs. | |
System | 3 | This is another catchall type of facility that is often over-used but generally related to system services, Unix daemons not otherwise classified. |
Security | 4 | These are messages related to security processing, such as login detection, virus protection, and intrusion detection systems. Other security-related messages are found in the Audit(13) and Alert(14) facilities. |
Internal | 5 | Originally, these were messages related only to the internal operations of the syslog protocol process, but have evolved to include general internal processes, often related to performance monitoring, but occasionally simply the internal workings of the system. |
Printer | 6 | These messages are related to the Unix lpd process, and can also indicate problems with printer hardware, printer queues, and other types of queues that are not particularly related to printers. |
News | 7 | These are messages related to the Network News processes, that has been fairly deprecated, although are still found on many Unix and mainframe systems. This facility is sometimes used to indicate low severity news events, such as a system being brought down. |
Network | 8 | These messages are related to the Unix uucpd process. (UUCP is an acronym for Unix to Unix Copy.) They might also refer to network events, such as interfaces being enabled or disabled. |
Lock | 9 | This facility is listed in the RFC as a clock, but is often renamed as a lock, and used for locking mechanisms, such as file locking queues. It is often substituted for the Clock(15) facility code. It might (on some systems) be identical to the Clock(15) facility. |
Auth | 19 | This is similar to the Security(4) facility but is generally reserved for authorization errors, such as invalid logins. It is somewhat synonymous with both Security(4) and Audit(13). It represents one of the areas of the RFC that is not clearly delineated, hence is subject to interpretation. |
FTP | 11 | These messages are related to the Unix ftpd process, and FTP program, that is somewhat deprecated but still in use. This facility is sometimes used for non-FTP protocol messages related to file transfers. |
NTP | 12 | These messages are related to the Unix ntpd (News Transport Protocol) processes. This is somewhat deprecated, but can still be found on a variety of Unix platforms. |
Audit | 13 | This is similar to the Security(4) and Auth(19) facility codes, but mainly appropriate for audit processing, including performance monitoring. |
Alert | 14 | This is a general-purpose (hence heavily overused) facility to indicate an Alert condition. This might be somewhat confusing because this is really a severity rather than a facility. Ideally, these messages would represent problems with the alerting process rather than actual alerts. |
Clock | 15 | These messages are related to the Unix clock daemons, and other processes involved with time synchronization and maintenance. This facility is also sometimes used to mark event times, such as by issuing a syslog message via the Unix cron or Unix at the program. Some scheduler programs use this facility. Occasionally, due to ambiguities in the RFC, this facility is confused with and substituted for the Lock(9) facility. |
Local0 | 16 | This is a user definable facility, used by Cisco and many other vendors. It is of use in application software and is an ideal candidate for being modified by the BMC Defender Server to provide a more meaningful facility name, based upon the message content. |
Local1 | 17 | This is another user-definable facility. See notes regarding the Local0(16) facility. |
Local2 | 18 | This is another user definable facility. See notes regarding the Local0(16) facility. |
Local3 | 19 | This is another user definable facility. See notes regarding the Local0(16) facility. |
Local4 | 20 | This is another user definable facility. In particular, this is commonly used by Red Hat clustering software, and is used by the Cisco PIX software, and is used in some Perl scripts. See notes regarding the Local0(16) facility for more information. |
Local5 | 21 | This is another user definable facility. See notes regarding the Local0(16) facility. |
Local6 | 22 | This is another user definable facility. See notes regarding the Local0(16) facility. |
Local7 | 23 | This is another user definable facility. See notes regarding the Local0(16) facility. |
Syslog severity codes and their meaning
The basic severities, defined by RFC 3164, are discussed as follows:
Severity | Code | Description |
|---|---|---|
Debug | 7 | The lowest severity, reserved strictly for debugging the system. In practice, debug messages can be totally ignored by everyone. |
Info | 6 | These are informational messages, that can be reviewed later (having some pertinence), but that can be operationally ignored because they have no effect on management activities. |
Notice | 5 | These are messages that are sent with the intention of being noticed. They have a fairly significant level of importance. A filter should generally not remove arbitrarily remove all messages with this severity. |
Warning | 4 | A significant message. It signifies a non-trivial degree of risk. There might not be any corrective action needed with this type of message. |
Error | 3 | A highly significant message. The message indicates that corrective action, manual intervention, or operational change is necessary. |
Critical | 2 | A critical situation exists that requires immediate attention. All other activities should be set aside, and the problem addressed as soon as possible. Possible risk to security or data or infrastructure is imminent. |
Alert | 1 | An extremely critical condition exists that requires immediate intervention by the highest levels of management, requiring whatever resources necessary to immediately fix. Data has been lost, security has been breached, or infrastructure has been damaged. |
Emergency | 0 | This severity should NEVER be used, reserved for situations where human safety or the overall health of the organization has been compromised or is in extreme jeopardy. |