Facility codes and their meaning
The basic facilities, defined by RFC 3164, are as follows:
Facility | Code | Description |
|---|---|---|
Kernel | 0 | These messages are 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 overused) 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 a catchall type of facility that is often overused, but generally relates to system services, Unix daemons that are not otherwise classified. |
Security | 4 | These messages are 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. 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 network events. This facility corresponds to the Unix uucpd process, that has been fairly well deprecated in the age of high-speed TCP networks. (UUCP is an acronym for Unix to Unix Copy.) |
Lock | 9 | This facility is listed in the RFC as clock, but is often renamed as lock, and is 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 | 10 | 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. For instance, a performance monitor might use this facility to periodically send the disk space and disk utilization statistics to the syslog process for data collection. The messages that use this facility should be pertinent to performance reporting. |
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 using the Unix cron or Windows at 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 often used 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 the row for the Local0 facility above. |
Local2 | 18 | This is another user definable facility. See the row for the Local0 facility above. |
Local3 | 19 | This is another user definable facility. See the row for the Local0 facility above. |
Local4 | 20 | This is another user definable facility. In particular, this is commonly used by RedHat 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 the row for the Local0 facility above. |
Local6 | 22 | This is another user definable facility. See the row for the Local0 facility above. |
Local7 | 23 | This is another user definable facility. See the row for the Local0 facility above. |
If you want to define your own syslog messages, in particular syslog messages generated by application programs, the Local0 through Local7 facilities are good candidates in the absence of other obvious alternatives.
Some firewalls and routers allow you to associate messages with specific facilities, in that case you can dedicate the Local0 through Local7 facilities to a router or firewall configuration, based upon some arbitrary enterprise policy. The BMC Defender Server can provide a more meaningful and descriptive facility name through a user defined facility that overrides one (or all) of the Local0 through Local7 standard facilities.
If you choose to use the Local type facilities, these messages should have unique content such that it makes it easy to filter and override. In practice, many developers attempt to wedge their message facility into one of the other more commonly defined facilities, but it is a good practice to define these facilities in the enterprise through some sort of written policy or operational guidelines, thereby promoting consistency (at least within the organization).
Related topic