Rsyslog vs Syslog-Ng:Choosing the Best

Rsyslog vs Syslog-Ng
Rsyslog vs Syslog-Ng

DISCLOSURE: This post may contain affiliate links, meaning when you click the links and make a purchase, we receive a commission.

When setting up a new device into a network, the first thing that comes to mind is how to enable communication between it and the central server. For example, in a case where you would want to debug an error in your router, and you want the status reports.

Well, this is such a common use case that there is a standardized logging protocol known as syslog used by network devices. Rsyslog and syslog-ng are examples of such a protocol.

If you want to learn more about how what features or functionality differentiate these two logging protocols, then keep reading for a detailed and informative deep dive into this exact topic.

What Is Syslog

Syslog is a network–based logging protocol. Similar to other web protocols, such as HTTP or SMTP, it defines the message semantics that network devices use to send their formatted logs to a central server.

Every network device needs to create data logs thus, essentially, every such device also runs a syslog agent. That being said, rsyslog and syslog-ng are improvements or replacements of the original syslog or syslogd daemon.

Rsyslog vs Syslog-Ng

Differences Between rsyslog And syslog-ng

Whilst both were presented as an upgrade over the original logging protocol known as syslogd, they take quite different routes in terms of their implementation. Rsyslog was originally just an improvement over syslogd as it was a fork of the same project. Using the same syntax as well.

Syslog-ng, on the other hand, had its own syntax implementation and was built from the ground up. The ‘ng’ actually stands for ‘next generation’. As such, it came out with a different syntax and more functionality and features over the original syslogd.


As a system administrator, simple, concise solutions are always better than ambiguous, complex ones. Concerning log collection, two essential factors play a huge role in adapting the logging infrastructure to a given system architecture.

The first one is the readable syntax of the configuration file, which you can understand quickly. The second one is proper documentation. It is a widely accepted notion that syslog-ng has more extensive and subjectively better quality documentation than rsyslog.

Most power users prefer using syslog-ng for this particular reason. Rsyslog, on the other hand, has very brief and bare-bones documentation. Examples are few and far between.

For syslog-ng almost all new features are documented by the time of the release of a new version, and older modified functions are also updated in the documentation right away. As a result, adoption is extremely easy, any example from the documentation can be copy pasted, and you can be sure that it will run without any issues.


Originally being a fork of syslogd (the original BSD syslog daemon), rsyslog maintained the same configuration as syslogd. For years it used the BSD syslog config syntax. Later on, it shifted to the newer syntax that syslog-ng was using.

This conversion was/is a source of confusion amongst users, especially older ones. On the other hand, syslog-ng has been using the same configuration since the start. So it has had the same syntax for more than twenty years.

This consistency instills confidence in end users and makes it so everything is backward compatible and users can study old code and learn from previously solved problems (looking at you, 15-year-old StackOverflow answers).


Being both free and open source, rsyslog became the logging implementation of choice for many Linux distributions. Unlike Windows and macOS, almost all Linux distributions are free. Thus, the underlying packages or software they use are free and/or open-source.

A tweezers with Linux logo penguin

This is where rsyslog has the advantage over syslog-ng. Syslog-ng has a commercial variant that is neither free nor fully open source. The commercial version doesn’t suit the need for average free Linux kernels. On the flip side, this is a massive consideration for corporate users.

They value a professional development team that delivers enterprise-level support regardless of the cost. Rsyslog falls short of this as it has no commercial version. Software support is hard to get, and using this in a commercial setup is not averse to risks. If the system fails due to a rsyslog issue, solving it would be the user’s responsibility.


For the longest time rsyslog was only available on Linux, it is only recently that Solaris also received support. Syslog-ng on the other hand is (and has been) supported on a plethora of different systems, from Linux and Solaris to lesser-known ones such as Tru64 and much more.

Thus if your setup requires compatibility across multiple devices, then syslog-ng should be your go-to logging system. In the case of modern servers, almost all systems are Linux based, so this feature becomes less of a requirement and more of a good-to-have feature.

Message Classes

Message classes are how the syslog-ng application sorts your logs so that they have some sort of inherent meaning to their organization. It does this by comparing new messages to a database of pre-defined patterns, if the message matches with any of the patterns it’s labeled as belonging to that message class.

So, say you wanted to quickly sift through only your error logs then you can do that efficiently using Syslog-ng’s message classes. They are sorted by a name-value pair thus you can access logs with error codes using the defined name for them in the message class syntax.

Rsyslog has no such implementation of message classes. Thus advanced functionality and features that come with the implementation remain missing.


While both offer almost the same functionality, it’s in the implementation of said functionality that the differences arise. If you plan to set up and debug your devices by yourself or use them in your organization, then syslog-ng is the preferred solution owing to its extensive documentation and the existence of a paid version with developmental support.

Office employees discussing project at laptop

On the other hand, if you just need a no-frills solution that’s tried and tested, then rsyslog is not a bad choice either. Here is a table condensing all the information we have discussed in this article.

DocumentationBrief and not comprehensiveDetailed and often updated
ConfigurationChanged after releaseStable syntax used for more than twenty years
UsabilityUsed more often in Linux DistrosUsed more often in commercial settings
CompatibilityAvailable for Linux or SolarisAvailable for a plethora of other systems apart from Linux
Message ClassesNot availableImplemented in syslog-ng


While initially being quite different, after the shift of rsyslog’s configuration, there remains few subtle technical differences between the two. If you value advanced functionality and good documentation, then syslog-ng might be the better choice for you.

If you value professional support or plan to use a logging system professionally, then rsyslog might be your best bet.