Written by Rainer Gerhards (2008-05-06)
We have often been asked about a comparison sheet between rsyslog and syslog-ng. Unfortunately, I do not know much about syslog-ng, I did not even use it once. Also, there seems to be no comprehensive feature sheet available for syslog-ng (that recently changed, see below). So I started this comparison, but it probably is not complete. For sure, I miss some syslog-ng features. This is not an attempt to let rsyslog shine more than it should. I just used the rsyslog feature sheet as a starting point, simply because it was available. If you would like to add anything to the chart, or correct it, please simply drop me a line. I would love to see a real honest and up-to-date comparison sheet, so please don't be shy ;)
| Feature | rsyslog | syslog-ng | |
Input Sources |
|||
| UNIX domain socket | yes | yes | |
| UDP | yes | yes | |
| TCP | yes | yes | |
| RELP | yes | no | |
| RFC 3195/BEEP | yes (via im3195) | no | |
| kernel log | yes | yes | |
| file | yes | yes | |
| mark message generator as an optional input | yes | no (?) | |
| Windows Event Log | via EventReporter or MonitorWare Agent (both commercial software) | via separate Windows agent, paid edition only | |
Network (Protocol) Support |
|||
| support for (plain) tcp based syslog | yes | yes | |
| support for GSS-API | yes | no | |
| ability to limit the allowed network senders (syslog ACLs) | yes | yes (?) | |
| support for syslog-transport-tls based framing on syslog/tcp connections | yes | no (?) | |
| udp syslog | yes | yes | |
| syslog over RELP truly reliable message delivery (Why is plain tcp syslog not reliable?) |
yes | no | |
| on the wire (zlib) message compression | yes | no (?) | |
| support for receiving messages via reliable RFC 3195 delivery | yes | no | |
| support for TLS/SSL-protected syslog | natively (since 3.19.0) via stunnel |
via stunnel paid edition natively |
|
| support for IETF's new syslog-protocol draft | yes | no | |
| support for IETF's new syslog-transport-tls draft | yes (since 3.19.0 - world's first implementation) |
no | |
| support for IPv6 | yes | yes | |
| native ability to send SNMP traps | yes | no | |
| ability to preserve the original hostname in NAT environments and relay chains | yes | yes | |
Message Filtering |
|||
| Filtering for syslog facility and priority | yes | yes | |
| Filtering for hostname | yes | yes | |
| Filtering for application | yes | yes | |
| Filtering for message contents | yes | yes | |
| Filtering for sending IP address | yes | yes | |
| ability to filter on any other message field not mentioned above (including substrings and the like) | yes | no | |
| support for complex filters, using full boolean algebra with and/or/not operators and parenthesis | yes | yes | |
| Support for reusable filters: specify a filter once and use it in multiple selector lines | no | yes | |
| support for arbritrary complex arithmetic and string expressions inside filters | yes | no | |
| ability to use regular expressions in filters | yes | yes | |
| support for discarding messages based on filters | yes | yes | |
| ability to filter out messages based on sequence of appearing | yes (starting with 3.21.3) | no | |
| powerful BSD-style hostname and program name blocks for easy multi-host support | yes | no | |
Supported Database Outputs |
|||
| MySQL | yes (native ommysql, omlibdbi) | yes (via libdibi) | |
| PostgreSQL | yes (native ompgsql, omlibdbi) | yes (via libdibi) | |
| Oracle | yes (omlibdbi) | yes (via libdibi) | |
| SQLite | yes (omlibdbi) | yes (via libdibi) | |
| Microsoft SQL (Open TDS) | yes (omlibdbi) | no (?) | |
| Sybase (Open TDS) | yes (omlibdbi) | no (?) | |
| Firebird/Interbase | yes (omlibdbi) | no (?) | |
| Ingres | yes (omlibdbi) | no (?) | |
| mSQL | yes (omlibdbi) | no (?) | |
Enterprise Features |
|||
| support for on-demand on-disk spooling of messages | yes | paid edition only | |
| ability to limit disk space used by spool files | yes | yes | |
| each action can use its own, independant set of spool files | yes | no | |
| different sets of spool files can be placed on different disk | yes | no | |
| ability to process spooled messages only during a configured timeframe (e.g. process messages only during off-peak hours, during peak hours they are enqueued only) | yes (can independently be configured for the main queue and each action queue) |
no | |
| ability to configure backup syslog/database servers | yes | no | |
| Professional Support | yes | yes | |
Config File |
|||
| config file format | compatible to legacy syslogd but ugly | clean but not backwards compatible | |
| ability to include config file from within other config files | yes | no | |
| ability to include all config files existing in a specific directory | yes | no | |
Extensibility |
|||
| Functionality split in separately loadable modules | yes | no | |
| Support for third-party input plugins | yes | no | |
| Support for third-party output plugins | yes | no | |
Other Features |
|||
| ability to generate file names and directories (log targets) dynamically | yes | yes | |
| control of log output format, including ability to present channel and priority as visible log data | yes | yes | |
| native ability to send mail messages | yes (ommail, introduced in 3.17.0) | no (only via piped external process) | |
| good timestamp format control; at a minimum, ISO 8601/RFC 3339 second-resolution UTC zone | yes | yes | |
| ability to reformat message contents and work with substrings | yes | I think yes | |
| support for log files larger than 2gb | yes | yes | |
| support for log file size limitation and automatic rollover command execution | yes | yes | |
| support for running multiple syslogd instances on a single machine | yes | ? (but I think yes) | |
| ability to execute shell scripts on received messages | yes | yes | |
| ability to pipe messages to a continously running program | no | yes | |
| massively multi-threaded for tomorrow's multi-core machines | yes | no (only multithreaded with database destinations) | |
| ability to control repeated line reduction ("last message repeated n times") on a per selector-line basis | yes | yes (?) | |
| supports multiple actions per selector/filter condition | yes | yes | |
| web interface | phpLogCon [also works with php-syslog-ng] |
php-syslog-ng | |
| using text files as input source | yes | yes | |
| rate-limiting output actions | yes | yes | |
| discard low-priority messages under system stress | yes | no (?) | |
| flow control (slow down message reception when system is busy) | yes (advanced, with multiple ways to slow down inputs depending on individual input capabilities, based on watermarks) | yes (limited? "stops accepting messages") | |
| rewriting messages | yes | yes (at least I think so...) | |
| output data into various formats | yes | yes (looks somewhat limited to me) | |
| ability to control "message repeated n times" generation | yes | no (?) | |
| license | GPLv3 (GPLv2 for v2 branch) | GPL (paid edition is closed source) | |
| supported platforms | Linux, BSD, anecdotical seen on Solaris; compilation and basic testing done on HP UX | many popular *nixes | |
| DNS cache | no | yes | |
While the rsyslog project was initiated in 2004, it is build on the main author's (Rainer Gerhards) 12+ years of logging experience. Rainer, for example, also wrote the first Windows syslog server in early 1996 and invented the eventlog-to-syslog class of applications in early 1997. He did custom logging development and consulting even before he wrote these products. Rsyslog draws on that vast experience and sometimes even on the code.
Based on a discussion I had, I also wrote about the political argument why it is good to have another strong syslogd besides syslog-ng. You may want to read it at my blog at "Why does the world need another syslogd?".
Balabit, the vendor of syslog-ng, has just recently done a feature sheet. I have not yet been able to fully work through it. In the mean time, you may want to read it in parallel. It is available at Balabit's site.