Rsyslog is an enhanced multi-threaded syslogd. Among others, it offers support for on-demand disk buffering, reliable syslog over TCP, SSL, TLS, and RELP, writing to databases (MySQL, PostgreSQL, Oracle, and many more), email alerting, fully configurable output formats (including high-precision timestamps), the ability to filter on any part of the syslog message, on-the-wire message compression, and the ability to convert text files to syslog. It is a drop-in replacement for stock syslogd and able to work with the same configuration file syntax.
LogAnalyzer is a Web front-end for syslog and other network event data. It provides easy browsing, searching, basic analysis, and some graphics. Data is taken from databases or plain syslog text files, so LogAnalyzer does not require changes to an existing logging infrastructure. Depending on the log data present, it can process syslog messages, Windows event log entries, and some more exotic things. Its troubleshooting support enables users to quickly find solutions to problems seen in the log data. LogAnalyzer was previously called phpLogCon, and has been renamed since v3.
I have to admit that I am also more than disappointed. Order by vitality/popularity is really missing as are the stats. More importantly, I find it very hard to describe the various branches of my project with the new "many links without structure" setting. Formerly, it was nice and clean, but now I have just a set of links that look really distracting to visitors. While I really value freshmeat, I think this mirgration is a move into the wrong direction. Not everything is bad because it is not xml ;)
Re: Good article.....
> Very good article, as it made me aware
> of rsyslogd. It sounds like the the
> setup is pretty straight forward,
> however, there's nothing I can't
> already do with syslog-ng (which ships
> with many Linux based distros). I
> could argue I can do more with syslog-ng
> (FIFO pipes, inserts into SQL
> databases, with a mix of perl/C/FIFO
> real time monitoring). Basically,
> rsyslogd reminds me a lot of a short
> lived project "msyslogd"
> (which I used).
> However, don't get me wrong.... I
> did enjoy the article and it's always
> nice to know alternatives out there.
Hi, I was a bit on the road, thus I follow up somewhat late. I fully understand your concerns and I am aware of it. Rsyslog is there for quite a while and (of course) I think it won't go away that fast. But I think the big question is "why another syslogd?" - I have blogged about this not so long ago, and you may like to have a look at the answer:
I would also like to mention that rsyslog has just become part of Fedora 8, so we are moving on. We already have the capability to work with backup destination (e.g. if one database server fails, try the next one) and there are other features syslog-ng does not yet offer. GSS-API has just been added, will be released soon. So I sincerely hope this will become a well-alive and useful project. Of course, there will always be differences to syslog-ng, as we do not to create a clone - why should that be useful... We try to do things a bit differently and hopefully hit the sweet pot ;)
Thanks again, Rainer