syslog

In computing, syslog is a widely used standard for message logging. It permits separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them.

Computer system designers may use syslog for system management and security auditing as well as general informational, analysis, and debugging messages. A wide variety of devices, such as printers and routers, and message receivers across many platforms use the syslog standard. This permits the consolidation of logging data from different types of systems in a central repository. Implementations of syslog exist for many operating systems.

Each message is labeled with a facility code, and assigned a severity label. The facility code indicates the software type of the application that generated the message.

The destination of messages may be directed to various destinations, tuned by facility and severity, including console, files, remote syslog servers, or relays.

Syslog message components

The information provided by the originator of a syslog message include the facility code and the severity level. The syslog software adds information to the information header before passing the entry to the syslog receiver. Such components include an originator process ID, a timestamp, and the hostname or IP address of the device.

Facility

A facility code is used to specify the type of program that is logging the message. Messages with different facilities may be handled differently. The list of facilities available is defined by RFC 3164:

Facility code	Keyword	Description
0	kern	kernel messages
1	user	user-level messages
2	mail	mail system
3	daemon	system daemons
4	auth	security/authorization messages
5	syslog	messages generated internally by syslogd
6	lpr	line printer subsystem
7	news	network news subsystem
8	uucp	UUCP subsystem
9		clock daemon
10	authpriv	security/authorization messages
11	ftp	FTP daemon
12	-	NTP subsystem
13	-	log audit
14	-	log alert
15	cron	scheduling daemon
16	local0	local use 0(local0)
17	local1	local use 1(local1)
18	local2	local use 2(local2)
19	local3	local use 3(local3)
20	local4	local use 4(local4)

The mapping between facility code and keyword is not uniform between operating systems and different syslog implementations.

Severity level

Value	Severity	Keyword	Description	Examples
0	Emergency	emerg	System is unusable	The level should not be used by applications.
1	Alert	alert	Should be corrected immediately	Loos of the primary ISP connection
2	Critical	crit	Critical conditions	A failure in the system’s primary application
3	Error	err	Error conditions	An application has exceeded its file storage limit and attempts to write are failing.
4	Warning	warning	May indicate that an error will occur if action is not taken	A non-root file system has only 2GB remaining.
5	Notice	notice	Events that are unusual, but not error conditions.
6	Informational	info	Normal operational messages that require no action.	An application has started, paused or ended successfully.
7	Debug	debug	Information useful to developers for debugging the application.

The meaning of severity levels other than emergency and debugging are relative to the application. For example, if the purpose of the system is to process transactions to update customer account balance information, an error in the final step should be assigned the alert level. However, an error occurring in an attempt to display the zip code of the customer may be assigned an error or even a warning level.

The server process which handles the message (syslogd) usually includes all lower levels. That is, if messages are separated by individual severity, a warning entry will be included in notice, info and debug processing.

Message

The message component has these fields: TAG, which should be the name of the program or process that generated the message, and CONTENT which contains the details of the message. The content field should be encoded in a UTF-8 character set and octet values in the traditional ASCII control character range should be avoided.

Network protocol

When operating over a network, syslog implements a client-server application structure. A server listens on a well-known port for protocol requests from clients. The most common Transport Layer protocol for network logging is the User Datagram Protocol (UDP), with the server listening on port number 514. UDP is unreliable, i.e. it does not guarantee the delivery of the messages. The use of UDP has been declared obsolete by RFC 5424 which states implementation must support Transport Layer Security (TLS) via the Transmission Control Protocol (TCP). Syslog over TLS uses port number 6514.

References

• syslog wiki

转载于:https://www.cnblogs.com/luckysimple/p/5070419.html