syslog-ng vs. rsyslog comparison

"I doubt that the syslogd compatibility would matter in a world, where the LINUX distros have not used syslogd for ages”
unknown system administrator

Make your work easier!

The syslog-ng application has several useful features not available in Rsyslog, for example the ability to classify, tag, and correlate log messages in real-time, but first off let’s have a look at a snippet picked up from the config file of syslog-ng from a major Linux distribution.

filter f_iptables { facility(kern) and message("IN=") and message("OUT=");
};
filter f_console { level(warn) and facility(kern) and not
filter(f_iptables) or level(err) and not
facility(authpriv); };
log { source(src); filter(f_console); destination(console); };
log { source(src); filter(f_console); destination(xconsole); };

Fairly readable, isn’t it? Let’s see the equivalent code snippet translated to rsyslog.conf.

if ( \
/* kernel up to warning except of firewall */ \
($syslogfacility-text == 'kern') and \
($syslogseverity <= 4 /* warning */ ) and not \
($msg contains 'IN=' and $msg contains 'OUT=') \
) or ( \
/* up to errors except of facility authpriv */ \
($syslogseverity <= 3 /* errors */ ) and not \
($syslogfacility-text == 'authpriv') \
) \
then /dev/tty10
& |/dev/xconsole

Can you see the difference? The configuration file of syslog-ng is clean, well-structured.Rsyslog's configuration format is an extension to the original syslog configuration, which is difficult to read, comprehend, or maintain.

In the above rsyslog example, the destination immediately follows the filter rule. If another destination needs a similar filter rule, it needs to be repeated in the config file. Filters in syslog-ng can be nested and reused for different destinations, making it more flexible and easy to maintain.

Find the quick solution!

The system administrators’ days can be very heavy, thus they always have to seek the quick solutions. Concerning log collection you certainly know that two essential factors play huge role adapting the logging infrastructure to a given system architecture. The first one is the readable syntax of configuration file, that you can understood quickly. The second one is the proper documentation.

The features and capabilites of syslog-ng are well-documented in the syslog-ng Administrator Guide. Rsyslog has no comprehensive documentation, and figuring out how to configure a particular feature can be difficult and time consuming.

Run it everywhere!

Rsyslog is mainly available for Linux and recently for Solaris. The syslog-ng application is highly portable and available for many more platforms including AIX, HP-UX, Linux, Solaris, Tru64 and most variants of BSD. This makes syslog-ng more suitable for sites with diverse platforms.

Utilize the message classes

The syslog-ng application can compare the contents of the log messages to a database of predefined message patterns, thus syslog-ng is able to identify the exact type of the messages, and sort them into message classes. The message classes can be used to classify the type of the event described in the log message. The message classes can be customized, and for example can label the messages as user login, application crash, file transfer, and so on.

Using patterns one can also extract important information and create name-value pairs from data found in log messages. These can be used for many different tasks: removing sensitive information from log files, creating files or database tables dynamically, etc. Name-value pairs can also help to standardize log information.

Recent versions of syslog-ng also make real-time event correlation possible. This can be useful in many different situations. For example important data for a single event is often scattered into multiple syslog messages. Also login and logout events are often logged far away from each other, even in different log files, making log analysis difficult. Using correlation these can be collected into a single new message.

Would you like to start an evaluation project with our professional assistance?