System Logging Protocol (Syslog) is a way network devices can use a standard message format to communicate with a logging server. It was designed specifically to make it easy to monitor network devices. Devices can use a Syslog agent to send out notification messages under a wide range of specific conditions.
These log messages include a timestamp, a severity rating, a device ID (including IP address), and information specific to the event. Though it does have shortcomings, the Syslog protocol is widely applied because it is simple to implement, and is fairly open-ended, allowing for a lot of different proprietary implementations, and thus the ability to monitor almost any connected device.
Syslog works on all flavors of Unix, Linux, and other *nix, as well as MacOS. Windows-based servers don’t support Syslog natively, but many third-party tools are available to allow Windows devices to communicate with a Syslog server.
Note: the term “Syslog” can variously refer to the actual server process or “daemon” (the Syslog daemon is called syslogd when someone is being precise), the message format, and the protocol. This happens with widely used systems that have been around for a while and have multiple uses.
Learn more about Syslog server best practices here.
A big advantage of syslog is that the log server can monitor a vast number of syslog events via log files. Routers, switches, firewalls, and servers can generate log messages, as well as many printers and other devices.
The syslog server receives, categorizes, and stores log messages for analysis, maintaining a comprehensive view of what is going on everywhere on the network. Without this view, devices can malfunction unexpectedly, and outages can be hard to trace.
Syslog messages are sent via User Datagram Protocol (UDP), port 514. UDP is what is called a connectionless protocol, so messages aren’t acknowledged or guaranteed to arrive. This can be a drawback but also leaves the system simple and easy to manage.
Syslog messages are often in a human-readable format but don’t need to be. In its header, each message has a priority level, which is a combination of a code for the process of the device creating the message and a severity level. The process codes, called “facilities”, are derived from UNIX. Severity levels range from 0 for emergency and 1 for immediate attention required, down to 6 for informational and 7 for debug messages.
Together, these two codes allow for quick classification of Syslog messages.
Because of the large amount of Syslog data that results from retaining all of these messages, a Syslog server needs a large database.
It also needs management and filtering software that enables the server to automatically generate alerts, alarms, and notifications. Filtering allows a sysadmin to easily call up files from a certain source, such as a firewall, for a specified time period.
On-screen popups or remote text messages can keep a sysadmin aware of any divergence from normal functioning. If there is some concern about a particular device, thresholds can be set lower, to more closely monitor messages of lower severity.
The Syslog data can be used in a variety of other ways, for example for detailed reporting, as well as the generation of diagrams to clarify the structure of the network.
Security Information and Event Management (SIEM) software provides a way to track, integrate, and analyze the vast amount of log data Syslog collects. Originally focused on compliance reporting, SIEM is now more widely used and can be a useful adjunct to Syslog.
Simple Network Management Protocol (SNMP) is another protocol for network device monitoring. SNMP works differently, getting most of its information by polling devices. Syslog servers can often accept SNMP data, particularly SNMP traps, that is, SNMP-enabled devices send without being polled.
SNMP is best for constrained situations with predictable conditions, while Syslog is both wider in scale and less constrained in format, and covers many different types of events.
In addition to Syslog, there are rsyslog and syslog-ng. Syslog is the original recipe, dating back to the early 1980s, while the other two are slightly differing flavors that have come out since.
Syslog-ng was begun in 1988 and adds some new filtering and encryption functions. Its syntax is not directly derived from syslog and so a syslog-ng server and syslog-ng configuration are somewhat different. You can learn more about how to install syslog-ng here.
Rsyslog dates from 2004, and is derived directly from Syslog, so it can be easily used as a replacement for it, since a syslog.conf file can be used in place of rsyslog.conf . Much like syslog-ng it also has improved ability to parse unstructured data and ship it to various destinations.
Both syslog-ng and rsyslog can also use TCP, TLS, and RELP, in addition to UDP.
Get our latest blog posts delivered in a weekly email.