A Review of Syslog-NG

After testing NXLog, rsyslog, syslog-ng, and logstash I’ve chosen syslog-ng open source as my primary logging application.  I wanted to try Graylog2 but I couldn’t tell from its practically nonexistent documentation whether or not it would meet my requirements.

Functional Requirements

The logging application had to meet the following functional requirements:

  • Syslog compatible
  • A drop-in replacement for the stock version of rsyslog included with CentOS 6.5
  • Ability to act as a syslog server
  • Ability to forward syslog logs to another server
  • Support for encrypted sockets
  • Supports user-defined log parsers
  • JSON output (formatter)
  • Support for Elasticsearch

rsyslog met all of these functional requirements. The others were very close. syslog-ng meets all but the Elasticsearch requirement. I chose it anyway because it best met my non-functional requirements. To me the non-functional weigh as much in my decision as the functional requirements. They include critical factors such as the usability of the software.

Non-functional Requirements

syslog-ng performed well. My throughput requirements are modest since my servers are measured in the tens. syslog-ng had no trouble keeping up and it’s memory footprint was small. Start-up was also very quick. It was compatible was SElinux and with my CentOS security configuration.

Installation was easy. The syslog-ng package can be downloaded directly from EPEL via yum. The package is signed. Once installed, I smoke-tested it by starting it immediately and it functioned just as I expected. Its default configuration worked as a drop-in replacement for rsyslog.

Like NXLog syslog-ng has a nice configuration file syntax. I found it easy to read and understand. Old style syslog configuration syntax is by comparison inscrutable. syslog-ng’s format uses a clear and explicit pipe-and-filter model that is conceptually easy to grasp. There are inputs, processors such as filters, and outputs. For example, this snippet mean send all system logs (sources_sys) to a central log server (d_log_server).

source s_sys {
 file ("/proc/kmsg" program_override("kernel: "));
 unix-stream ("/dev/log");

destination d_log_server {
 tcp("" port(514) flags(syslog-protocol) );

log { 

It also offers a sophisticated log parsing engine with a syntax similar to OSSEC’s.

It’s documentation is very good. Balabit has produced a nice administration manual that covers the key tasks and explains the complete syntax of each command. For situations not covered in the Manual, I have been able to find answers to my questions via the Internet in blogs and forums.

A Note on rsyslog

Why not rsyslog since it meets all my functional requirements? I spent a lot of time trying to get rsyslog to work. I finally gave up in frustration due to the very poor documentation. I wanted to use rsyslog’s new syntax and its custom parsing ability. Due to the lack of documentation I couldn’t get either to work. In contrast, syslog-ng’s good documentation enabled me to accomplish my tasks quickly. When you are trying to get 30 or so infrastructure applications working who want to spend all your time trying to figure out just one of them?


I’ve been using syslog-ng for a couple of months now and it has worked well. I haven’t had any problems with it. If you are looking for a logging application syslog-ng is worth your time testing.

Categories: Software

Tags: ,

5 replies

  1. What were your thoughts regarding NxLog? Why did you pick syslog-ng over nxlog?


    • Hi Rodrigo,

      I wrote a short review of NxLog in this post. The reasons I picked Syslog-NG on NXLog were:

      • It was packaged as an RPM and available via EPEL making installation easy to automate. The RPM was signed as well.
      • It works with SELinux. I had trouble making NXLog work which I now think is probably due to SELinux.
      • It works out-of-the-box as an rsyslog replacement. It’s default configuration file mirrors the CentOS default.
      • I prefer its log parsing engine to create structured log files.

      Both have good documentation (unlike rsyslog), a readable and modern configuration format, perform well, and support SSL. It’s close but I thought that Syslog-NG was better packaged for my environment CentOS Linux.



  2. I implemented a centralised logging system about two years ago. At that time I tested the same solutions as you (+Splunk). Unfortunately I was forced to go with rsyslog as I had the undroppable functional requirement of persistent client-side buffering and rsyslog was the only solution supporting it.

    Has the situation changed since then? Is syslog-ng now able to do client-side buffering on disc while the central server is unavailable?

    BTW rsyslog is a nightmare:

    • worst configuration syntax ever (both the oldest, old and new syntaxes are terrible)
    • unexpected “features” (tries to handle/parse malformed syslog packets, imfile module skips parts of lines if writes doesn’t always end with a newline etc.)
    • bugs (segfaults in more complexconfigurations)
    • unusable status information (e.g. if an rsyslog server receives logs from sources and also sends logs to targets and the targets become unavailable, the sources become not able to send their logs until they are restarted)

    I would definitely put time and effor to a replacement project if syslog-ng were able to satisfy my needs…


    • Hello Zoltan,

      Syntax is a big issue for me as well and it’s one of the reasons I choose syslog-ng over rsyslog. I’m not sure if this will meet your requirements but my syslog-ng client configuration stores all logs locally as well as sending them to a central server. You can see it on my GitHub page: https://github.com/aaron868/management/blob/master/roles/syslog-ng-client/templates/syslog-ng.conf.j2

      syslog-ng supports multiple destinations and the syntax is very straightforward. I do not know if it buffers the logs destined for the servers when the server connection is down and then sends them when the connection comes back up. I should test that. In any event there is always the local copy as backup.



  1. LOADays 2014 « Czanik@BalaBit

Share Your Ideas

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: