출처 :   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

+ Recent posts