Rsyslog has been forked in 2004 from the sysklogd standard package. The goal of the rsyslog project is to provide a feature-richer and reliable syslog deamon while retaining drop-in replacement capabilities to stock syslogd. By "reliable", we mean support for reliable transmission modes like TCP or RFC 3195 (syslog-reliable). We do NOT imply that the sysklogd package is unreliable.
The name "rsyslog" stems back to the planned support for syslog-reliable. Ironically, the initial release of rsyslog did NEITHER support syslog-reliable NOR tcp based syslog. Instead, it contained enhanced configurability and other enhancements (like database support). The reason for this is that full support for RFC 3195 would require even more changes and especially fundamental architectural changes. Also, questions asked on the loganalysis list and at other places indicated that RFC3195 is NOT a prime priority for users, but rather better control over the output format. So there we were, with a rsyslod that covers a lot of enhancements, but not a single one of these that made its name ;) Since version 0.9.2, receiving syslog messages via plain tcp is finally supported, a bit later sending via TCP, too. Starting with 1.11.0, RFC 3195 is finally support at the receiving side (a.k.a. "listener"). Support for sending via RFC 3195 is still due. Anyhow, rsyslog has come much closer to what it name promises.
The database support was initially included so that our web-based syslog interface could be used. This is another open source project which can be found under http://www.phplogcon.org. We highly recommend having a look at it. It might not work for you if you expect thousands of messages per second (because your database won't be able to provide adequate performance), but in many cases it is a very handy analysis and troubleshooting tool. In the mean time, of course, lots of people have found many applications for writing to databases, so the prime focus is no longer on phpLogcon.
Rsyslogd supports an enhanced syslog.conf file format, and also works with the standard syslog.conf. In theory, it should be possible to simply replace the syslogd binary with the one that comes with rsyslog. Of course, in order to use any of the new features, you must re-write your syslog.conf. To learn how to do this, please review our commented sample.conf file. It outlines the enhancements over stock syslogd. Discussion has often arisen of whether having an "old syslogd" logfile format is good or evil. So far, this has not been solved (but Rainer likes the idea of a new format), so we need to live with it for the time being. It is planned to be reconsidered in the 3.x release time frame.
If you are interested in the IHE environment, you might be interested to hear that rsyslog supports message with sizes of 32k and more. This feature has been tested, but by default is turned off (as it has some memory footprint that we didn't want to put on users not actually requiring it). Search the file syslogd.c and search for "IHE" - you will find easy and precise instructions on what you need to change (it's just one line of code!). Please note that RFC 3195/COOKED supports 1K message sizes only. It'll probably support longer messages in the future, but it is our believe that using larger messages with current RFC 3195 is a violation of the standard.
In February 2007, 1.13.1 was released and served for quite a while as a stable reference. Unfortunately, it was not later released as stable, so the stable build became quite outdated.
In June 2007, Peter Vrabec from Red Hat helped us to create RPM files for Fedora as well as supporting IPv6. There also seemed to be some interest from the Red Hat community. This interest and new ideas resulted in a very busy time with many great additions.
In July 2007, Andrew Pantyukhin added BSD ports files for rsyslog and liblogging. We were strongly encouraged by this too. It looks like rsyslog is getting more and more momentum. Let's see what comes next...
Also in July 2007 (and beginning of August), Rainer remodled the output part of rsyslog. It got a clean object model and is now prepared for a plug-in architecture. During that time, some base ideas for the overall new object model appeared.
In August 2007 community involvment grew more and more. Also, more packages appeared. We were quite happy about that. To facilitate user contributíons, we set up a wiki on August 10th, 2007. Also in August 2007, rsyslog 1.18.2 appeared, which is deemed to be quite close to the final 2.0.0 release. With its appearance, the pace of changes was deliberatly reduced, in order to allow it to mature (see Rainers's blog post on this topic, written a bit early, but covering the essence).
Be sure to visit Rainer's syslog block to get some more insight into the development and futures of rsyslog and syslog in general. Don't be shy to post to either the blog or the rsyslog forums.