推理文by阿誠

Syslog Facilities

A BSD Unix Syslog message looks like this:
<PRI>HEADER MESSAGE

The priority is a value from 0 to 191 and is not space or leading zero padded.
For more information on the Syslog message format, please read the RFC.

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 suggested you 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

Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to
191 and is made up of a Facility value and a Level value. The priority is enclosed in "<>" delimiters.
A BSD Unix Syslog message looks like this:

<PRI>HEADER MESSAGE

The priority is a value from 0 to 191 and is not space or leading zero padded.
For more information on the Syslog message format, please read the RFC.
The priority value is calculated using the following formula:

Priority = Facility * 8 + Level

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.

A detailed explanation of the severity Levels:

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 - notify all tech staff on call? (earthquake? tornado?) - affects multiple apps/servers/sites...