Syslog: Difference between revisions

From Halfface
Jump to navigation Jump to search
Line 59: Line 59:


==Severity levels==
==Severity levels==
[http://tools.ietf.org/html/rfc5424 RFC 5424] defines eight severity levels:


{| class="wikitable"
{| class="wikitable"

Revision as of 13:31, 12 June 2012

Messages refer to a facility (auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7 ) and are assigned a severity (Emergency, Alert, Critical, Error, Warning, Notice, Info or Debug) by the sender of the message.

Configuration allows directing messages to various local devices (console), files (/var/log/) or remote syslog daemons. Care must be taken when updating the configuration as omitting or misdirecting message facilities or severities can cause important messages to be ignored by syslog or overlooked by the administrator.

Facility Levels

Facility Number Facility Description
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)

Severity levels

Code Severity Description General Description
0 Emergency System is unusable. A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call.
1 Alert Action must be taken immediately. Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a backup ISP connection.
2 Critical Critical conditions. Should be corrected immediately, but indicates failure in a primary system, an example is a loss of primary ISP connection.
3 Error Error conditions. Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time.
4 Warning Warning conditions. 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.
5 Notice Normal but significant condition. 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.
6 Informational Informational messages. Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.
7 Debug Debug-level messages. Info useful to developers for debugging the application, not useful during operations.