As a de facto standard for computer message logging, syslog has been around many years. Fundamentally, every Linux and Unix variant delivers some level of syslog message logging as a default.

Like any other logging capability, syslog must be enabled to work and the user needs to decide what to do with the data being logged. The choice of destination can be as simple as log files or you can use database logging, where syslog writes directly to a fully relational database engine.

The Syslog Protocol

Syslog is an IETF standards track protocol with reference document RFC 5424 first issued in 2009. As with any IETF standard, the current status and definitions can be found at the Official Internet Protocol Standards website. The information found in this standard obsoleted the original BSD Unix standard , RFC 3164, which was an informational document, rather than a standards proposal. Additional IETF standards documents cover TLS Transport Mapping for Syslog (RFC 5425) and Transmission of Syslog messages over UDP (RFC 5426).


Syslog-ng is an extension of the basic syslog protocol currently developed by Balabit IT Security. This open source code supports most distributions of Linux and Unix, both open source and proprietary. Some distributions install it as the default syslog, and there is even a Cygwin port for Microsoft Windows. Syslog-ng was the first version to support logging directly into a database, log to multiple files destinations, directing log messages to local applications, extract structured data from unstructured messages and a number of other features which are now consider standard to the syslog environment. Both open source and proprietary versions of syslog can be obtained on the Balabit IT Security website.


Rsyslog is the rocket-fast system for log processing, an open source project started in 2004 with the goal of building a faster and more flexible syslog implementation. Version 7 (currently version 7.6.3) was released in December 2013 and a re-engineered Version 8.2.0 in April 2014. Both versions are currently supported by the open source community and can be found on the rsyslog home page at

Because much of the development of syslog tools stared with the information RFC 3164 there are many branches which have incompatible extensions. One of the goals of rsyslog was to enable a service that would work with as many of the branches as possible as well as support the later RFC standards discussed earlier. The performance claims for rsyslog are also much greater than for other existing standardized implementations as well as the supported sources and destinations for data. Direct database logging to both open source and commercial databases is supported as well as source messaging from Linux, Unix, and Microsoft Windows devices. This graphic, from the rsyslog home, gives you some ideas of the logging capabilities.

Configuring rsyslog for the Collector

Some systems require you to configure rsyslog directly to send logs to the InsightOps Collector. To do so, complete the following steps:

  1. As superuser, edit the file /etc/rsyslog.conf
  2. Add the following line to the end of the file:
# Send logs to the InsightOps Collector
*.* @@
  1. In a terminal window, restart rsyslog with the following command:
> sudo service rsyslog restart
  1. In the above example, syslog is configured to send logs to TCP port 10514 on the machine running at IP Change the line in the example to match the location and port that the Collector's event source is running on in your environment.

NOTE: In rsyslog, UDP ports are described with a single '@', so to send to UDP port 1234 on a machine running at, you would write:

*.* @