Rsyslog is an enhanced multi-threaded syslogd with a focus on security and reliability. 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.
Its advanced features make it suitable for enterprise-class, encryption protected syslog relay chains while at the same time being very easy to setup for the novice user. An optional web interface - phpLogCon - can be used to visualize all data online. In November 2007, rsyslog has become the default syslogd for the Fedora project.
We have just released rsyslog 5.5.2, a member of the v5-devel branch. Rsyslog 5.5.2 primarily provides bug-fixes, but offers an enhanced functionality to escape 8-bit characters on reception. See Changelog for more details.
We have released a new v5-beta, version 5.3.7. Most importantly, it contains the fixes for the problem with named pipes that Michael Biebl discovered. There are also some other fixes (see changelog for detail). No new functionality is included.
Once again, this is scheduled to become the new v5-stable, if no further issues exist. As such, we would appreciate if you could try out the version and report back your experience (even if everything works).
See Changelog for more details.
We have just released rsyslog 5.3.6, a new v5-beta. Note that this version contains a number of bug fixes, some of them important for some environments. As usual for a beta, it does not contain anything else but fixes. The full list can be seen in the change log.
Please note that it is our intent to replace the current (instable ;)) v5-stable by this beta soon. So we would appreciate feedback on 5.3.6 - if we get a few thumbs up, we may be able to accelerate promoting 5.3.6 to stable.
An update for the current master branch will happen soon.
We have just released rsyslog 5.5.1, a member of the v5-devel branch. The primary new feature is that the epoll() interface is now supported for plain tcp syslog. This results in better performance and also removes the upper bound of connections in select() in a portable way. The select() interface is still supported for platforms that do not provide epoll(). There are also some important fixes. It is a recommended update for all users of the v5-beta. See Changelog for more details.
We have just released rsyslog 5.5.0, a member of the devel branch. The 5.5.0 version begins a new development branch. The primary new functionality in that release is moving away reverse DNS resolution from the udp receiver's input thread to backend processing, what should reduce UDP message loss.
We have just released rsyslog 4.5.7, a member of the v4-beta branch. Most importantly, a so-called "On Demand Debug" mode was added, in which debug output can be generated only after the process has started, but not right from the beginning. This is assumed to be useful for hard-to-find bugs. Also improved the doc on the debug system.
Today, we released a new v5-beta branch. It bases on the last v5-devel, plus has some bug fixes and some enhancements. The enhancements provide a slightly increased performance. This release is a very important milestone. Based on feedback from the v5-devel branches, it is in pretty good shape. Our aim is to have a quick beta phase this time (taking the problems with the current v5-stable) into account. To do so, we need your cooperation. Please try out this new version and report back any issues you may experience. It would also be good to know if you use it and do not run into any issues.
We have just released rsyslog 4.5.6, a member of the v4-beta branch. This is a bug-fixing release. Most importantly, named pipe support in actions has been re-enabled (it did not work due to a bug introduced in 4.5.0) and a number of memory addressing issues, which could lead to a segfault, have been solved. See Changelog for more details.
We have just released rsyslog 5.3.4, a member of the v5-devel branch.
Today's release offers a number of important improvements. I would like to highlight the ability to nest rulesets [1] (I already announced that) and the ability to define custom parsers [2].
Let me elaborate a bit on the later. In the syslog world exists a myriad of incompatible and invalidly formatted messages. We have had numerous support requests on how to parse this or that malformed message format. With custom parsers, we now have a vehicel to integrate all these invalid formats in an elegant way that is also offering high performance ([2] has a concrete sample). The core idea now is that parsers are plugins just like input and output modules. It is relatively easy to write such a parser (roughly a day, I expect) and custom parsers can be integrated into rsyslogd in a way that they only affect messages received on specific port. So far, I have not actually created a custom parser, but I hope that over time many of them will become available. My hope here is that we actually can build a directory, which other folks can browse so that they are able to find a solution to the mess their vendor has provided ;)
This release also introduces the capability to run rulesets off their own queue (also already mentioned on the mailing list). Plus, it contains the usual set of bug fixes.
We plan to make this version the basis for the next v5-stable.
We have just released rsyslog 5.2.0, a member of the v5-stable branch.
This is a re-release of version 5.1.6 as stable after we did not get any bug reports during the whole beta phase. Still, this first v5-stable may not be as stable as one hopes for, I am not sure if we did not get bug reports just because nobody tried it. Anyhow, we need to go forward and so we have the initial v5-stable.
·Re: templates and database well, I think my previous post was not so clear, anyway I'd like ... ·Re: Kernel logging oh, and one question to the original poster: you say that kernel ... ·Re: Kernel logging just for the others following this thread: I analyzed the debug l ... ·Re: no MARK in logs forgot to include the version: rsyslog 4.2.0-2ubuntu5.1 Ubuntu 9 ... ·Re: no MARK in logs rgerhards wrote:did you make sure that no messages appear during ... ·Re: no MARK in logs did you make sure that no messages appear during the mark message ... ·no MARK in logs Hi!I'm new user of rsyslog. I tried to find solution in doc but n ... ·Re: Kernel logging rgerhards wrote:can you provide a debug log?Trace sent at your pr ...
