What is syslog?
Syslog is a protocol that computer systems use to send event data logs to a central location for storage. Logs can then be accessed by analysis and reporting software to perform audits, monitoring, troubleshooting, and other essential IT operational tasks.
The go-to logging method since the 1980s, the syslog protocol has maintained its popularity through its ease of use, making it simple and straightforward to transport event log messages.
Perhaps the most convenient feature supporting this simplicity is the layered architecture, which enables users to put across messages using a number of different protocols. Additionally, when users need to provide vendor-specific extensions, the syslog message format allows them to do so within a structured framework.
How does syslog work?
Although it has been popular for decades, syslog hasn’t always been easy to define, due to lack of standardization. In 2009, the IETF standardized syslog, making it possible to sum up the protocol.
There are three layers to syslog: content, application, and transport.
The transport layer sends the message over a network.
The application layer enables the message to be routed around, interpreted, and stored.
The content layer is the actual data contained within the message, which contains several standardized informational elements, including facility codes and severity levels.
Understanding syslog messages
Syslog event messages are generated by individual applications or other components of a system. All syslog messages follow a standard format, which is required for sharing messages between applications. This format includes the following components:
A header that includes specific fields for priority, version, timestamp, hostname, application, process ID and message ID.
Structured data, with data blocks in the key-value format.
A message, to be UTF-8 encoded. Includes a tag identifying the process that triggered the message, along with the content of the message.
Syslog facility codes
To identify the source of a message, syslog uses a numeric facility code, or simply a “facility,” generated by the originator of the message. These codes originated in Unix systems, and aren’t obvious based on their values. The list below correlates the message code with its facility.
0: kernel messages
1: user-level messages
2: mail system
3: system daemons
4: security/authorization messages
5: messages generated internally by syslog
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
There are also facility codes 16 through 23, which are designated local use. This means they are used in differing capacities depending on the unique applications or software generating data in your specific system.
Syslog message levels
The syslog message is also tagged with a numeric severity indicator, with 0 being a full-on emergency and 7 used for debug purposes.
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
The communication path of a syslog message includes a message originator, which creates and sends the message, and a collector, which takes in and stores the message (i.e., logging server). It can also include relay points in between, which can involve some data processing as the message is sent on. Syslog messages can also be sent to multiple destinations, based on the originating application’s settings.
Syslog data collection
On the log server side, there are also some concepts to help define the process of collecting syslog data:
Listener: Gathers the syslog data over a UDP port. Because UDP does not notify on transmission, a TCP port may be used for this. The listener cannot request data, differentiating it from other collector types.
Database: Syslog can generate large amounts of data, and servers need to be configured to handle the volume.
Software for data handling: Running on top of the server data, software can help automate tasks that are not built in to the syslog process, making the data more usable.
No comments:
Post a Comment