Written by Rainer Gerhards (2008-02-15)
We have often been asked abut 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 |
| support for on-demand on-disk spooling of messages | yes | paid edition only |
| ability to configure backup syslog/database servers | yes | no |
| 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 | not sure... |
| good timestamp format control; at a minimum, ISO 8601/RFC 3339 second-resolution UTC zone | yes | ? (I guess so) |
| 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 filter on any part of the message, not just facility and severity | yes | yes |
| ability to use regular expressions in filters | yes | yes |
| support for discarding messages based on filters | yes | ? |
| ability to execute shell scripts on received messages | yes | yes |
| ability to pipe messages to a continously running program | no | yes |
| powerful BSD-style hostname and program name blocks for easy multi-host support | yes | no |
| 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 (?) |
| 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 |
| supports multiple actions per selector/filter condition | yes | ? |
| plug-in interface | yes | no |
| Windows Event Log gatherer | via EventReporter or MonitorWare Agent (both commercial software) | via Windows agent, paid edition only |
| config file format | compatible to legacy syslogd but ugly | clean but not backwards compatible |
| 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) | limited (TCP Window, delay on queue full) | yes (limited, too? "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 | many popular *nixes |
| DNS cache | no | yes |
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 |
| on the wire (zlib) message compression | yes | no (?) |
| support for receiving messages via reliable RFC 3195 delivery | yes | no |
| support for ssl-protected syslog | via stunnel | via stunnel paid edition natively |
| support for IETF's new syslog-protocol draft | yes | no |
| support for IPv6 | yes | yes |
| native ability to send SNMP traps | yes | ? |
| ability to preserve the original hostname in NAT environments and relay chains | yes | yes |
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 (?) |
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.
This document is current as of 2008-02-15 and definitely incomplete (I did not yet manage to complete it!).