출처 : http://en.wikipedia.org/wiki/Syslog
Syslog
From Wikipedia, the free encyclopedia
Syslog is a standard for computer data logging. It separates the software that generates messages from the system that stores them and the software that reports and analyzes them.
Syslog can be used for computer system management and security auditing as well as generalized informational, analysis, and debugging messages. It is supported by a wide variety of devices (like printers and routers) and receivers across multiple platforms. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository.
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.
logger is a command line utility that can send messages to the syslog.
Some implementations permit the filtering and display of syslog messages.
Syslog is now standardized within the Syslog working group of the IETF.
History
Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project, and was initially used solely for Sendmail. It proved so valuable that other applications began using it as well. Syslog has since become the standard logging solution on Unix and Unix-like systems; there have also been a variety of syslog implementations on other operating systems and is commonly found in network devices such as routers.
Syslog functioned as a de facto standard, without any authoritative published specification, and many implementations existed, some of which were incompatible. The Internet Engineering Task Force documented the status quo in RFC 3164. Since then, additions to syslog have been worked on. RFC 3164 was made obsolete by RFC 5424
At different points in time, various companies have attempted patent claims on syslog. This had little effect on the use and standardization of the protocol.
Outlook
Various groups are working on draft standards detailing the use of syslog for more than just network and security event logging, such as its proposed application within the health care environment.
Regulations, such as SOX, PCI DSS, HIPAA, and many others are requiring organizations to implement comprehensive security measures, which often include collecting and analyzing logs from many different sources. Syslog has proven to be an effective format to consolidate logs, as there are many open source and proprietary tools for reporting and analysis. Converters exist from Windows Event Log as well as other log formats to syslog.
An emerging area of managed security services is the collection and analysis of syslog records for organizations. Companies calling themselves Managed Security Service Providers attempt to apply analytics techniques (and sometimes artificial intelligence algorithms) to detect patterns and alert customers of problems.
Facility Levels
The list of Facilities available:
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
RFC 5424 defines eight 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. |
'::: 오픈소스 ::: > Rsyslog/LogAnalyzer' 카테고리의 다른 글
Rsyslog 개념 (0) | 2012.05.08 |
---|---|
Syslog-ng 개념 (0) | 2012.05.08 |