What is syslog?

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.

1. The transport layer sends the message over a network.
2. The application layer enables the message to be routed around, interpreted, and stored.
3. 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.

Advantages and disadvantages of syslog

Capturing log data is critical in modern business. Administrators, DevOps teams, and systems analysts use the information to maintain healthy functioning of systems, troubleshoot problems, better serve users, and much more. And with the complexity of modern business systems, capturing and analyzing large volumes of data can be a significant undertaking.

Of course, for data to be helpful for analysis, it needs to be transferred and collected in a central location, and it needs to be interpreted consistently across applications. Syslog is helpful in this context because it offers a standard for easily exchanging log information.

Syslog does, however, come with a few drawbacks. It does not include an authentication mechanism and is therefore weak on security. Additionally, it is possible to lose syslog messages because of its reliance on UDP transport. Finally, although there are standards about the components of a message, there is a lack of consistency in terms of how syslog messages’ content is formatted. And this means some messages will be more or less useful than others, in terms of human readability.

Regardless, syslog remains an overwhelmingly popular option for logging event data on networks.

Using syslog with Unix, Linux, and Mac OS

The syslog protocol has its roots in Unix, and it can run natively within a Unix or Unix-like environment. A user wishing to implement a syslog management tool can simply install syslog-ng using the included package management tools in the operating system.

Windows, on the other hand, does not come with syslog at the ready. Instead, it’s packaged logging protocol is the Windows Event Log. And while third-party applications can use this log, they frequently log events directly in the file system, which is less than ideal. As such, Windows users will generally want to implement a syslog client to enable the messaging protocol on their networks.

Keep in mind, as you evaluate syslog agents for Windows, that some programs only function to translate Windows Event Log messages in to syslog messages. Preferably, the tool should work with both Windows Event Log messages and files, since log messages are frequently being created in the filesystem.

Getting started with syslog

If you are ready to start using your syslog data to improve the performance of your networks, better understand application behaviors, or for any number of purposes, the centralized log management capabilities of Sumo Logic can help you overcome the challenges of the syslog protocol.

Sumo Logic syslog sources connect just like a typical syslog server, but they bring you a range of automation and analysis capabilities that don’t come built in to your systems. Learn how to connect Sumo Logic with syslog to get started.

Additional Resources

• How to Monitor Syslog Data with Sumo Logic