A question I often receive is ‘what are the differences between rsyslog and syslog-ng?’ It’s a little tricky to answer. First, because my experience is mostly with syslog-ng, and because there are many similarities between the two projects. This is where the syslog-ng users help me. They can clearly explain from firsthand experience why they chose syslog-ng. The following blog post includes some of the most common reasons why they choose syslog-ng.
It is not a technical feature, but still the most common answer I received from users. Especially from our power users who are very specific about the quality of documentation. It is an important deciding factor in choosing syslog-ng.
So you can adopt right away, the vast majority of new features are already documented by the time of release. And not just new features, but also changes affecting older features. Each release has its own documentation, meaning that you can copy and paste example configurations from the documentation and it will work.
The rsyslog configuration syntax has changed significantly over the years from something close to the original syslogd configuration to what we have today. On the other hand, configuration of syslog-ng practically stayed the same for over twenty years.
There are many different building blocks in the syslog-ng configuration, such as sources, filters and destinations. These building blocks are connected by using log statements to create pipelines. Of course there are now many more building blocks. You can also create your own configuration blocks and even declare some of the building blocks in-line in a log statement. Despite this growth in syslog-ng building blocks, conceptually the configuration has remained the same.
While configuration of syslog-ng looks daunting at first glance, after a bit of practice the elegant logic of it becomes obvious. This means that you can easily write complex configurations for syslog-ng. This is why I often hear that syslog-ng is deployed on relays and central syslog servers, even if clients run rsyslog or other software.
About a decade ago, rsyslog became the syslog implementation of choice for many Linux distributions. syslog-ng has a commercial variant, but it is not fully open source. While having a commercial variant was a disadvantage at Linux distributions, it is a major advantage at corporate users. The deciding factor for large companies is our professional development team that delivers enterprise level support, even if they keep using the open source edition.
But our ease of installation means that even if syslog-ng is not the default syslog implementation, we often become the central log management solutions. Most Linux distributions include syslog-ng either in the main repository or in external repositories, like EPEL for RHEL and CentOS users. The version of syslog-ng available from official distribution repositories might not be the most recent release. This is why for major Linux distributions there are unofficial syslog-ng repositories available, providing not just the latest version but also more features when a necessary dependency is missing from a given distribution.