mirror of
https://github.com/rsyslog/rsyslog.git
synced 2025-12-19 22:00:42 +01:00
129 lines
8.7 KiB
HTML
129 lines
8.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html><head>
|
|
<title>rsyslog history</title></head>
|
|
<body>
|
|
<h1>RSyslog - History</h1>
|
|
|
|
<b>Rsyslog is a GPL-ed, enhanced syslogd. Among others, it offers support for
|
|
reliable syslog over TCP, writing to
|
|
MySQL databases and fully configurable output formats (including great timestamps).</b>
|
|
Rsyslog was initiated by <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a>.
|
|
If you are interested to learn why Rainer initiated the project, you
|
|
may want to read his blog posting on "<a href="http://rgerhards.blogspot.com/2007/08/why-does-world-need-another-syslogd.html">why
|
|
the world needs another syslogd</a>".<p>Rsyslog has
|
|
been forked in <b>2004</b> from the <a href="http://www.infodrom.org/projects/sysklogd/">sysklogd standard package</a>.
|
|
The goal of the
|
|
rsyslog project is to provide a feature-richer and reliable
|
|
syslog daemon while retaining drop-in replacement capabilities to stock
|
|
syslogd. By "reliable", we mean support for reliable transmission
|
|
modes like TCP or <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a>
|
|
(syslog-reliable). We do NOT imply that the sysklogd package is unreliable.</p>
|
|
<p>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 rsyslogd 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 supported 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.</p>
|
|
<p>
|
|
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 <a href="http://www.phplogcon.org">http://www.phplogcon.org</a>. 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.
|
|
|
|
</p>
|
|
<p>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 <a href="sample.conf.php">sample.conf</a>
|
|
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.
|
|
</p><p>If you are interested in the <a href="http://en.wikipedia.org/wiki/IHE">IHE</a>
|
|
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.</p><p>In <b>February 2007</b>, 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.</p><p>In <b>June 2007</b>, 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.</p><p>In <b>July 2007</b>, 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...</p><p>Also in <b>July 2007</b> (and beginning of
|
|
August), Rainer remodeled 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.</p><p>In <b>August 2007</b>
|
|
community involvement grew more and more. Also, more packages appeared. We were
|
|
quite happy about that. To facilitate user contributions, we set up a
|
|
<a href="http://wiki.rsyslog.com/">wiki</a> 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 deliberately reduced,
|
|
in order to allow it to mature (see Rainers's
|
|
<a href="http://rgerhards.blogspot.com/2007/07/pace-of-changes-in-rsyslog.html">
|
|
blog post</a> on this topic, written a bit early, but covering the essence).</p><p>
|
|
In <b>November 2007</b>, rsyslog became the default syslogd in Fedora 8.
|
|
Obviously, that was something we *really* liked. Community involvement also is
|
|
still growing. There is one sad thing to note: ever since summer, there is an
|
|
extremely hard to find segfault bug. It happens on very rare occasions only and
|
|
never in lab. We are hunting this bug for month now, but still could not get
|
|
hold of it. Unfortunately, this also affects the new features schedule. It makes
|
|
limited sense to implement new features if problems with existing ones are not
|
|
really understood.</p><p><b>December 2007</b> showed the appearance of a postgres
|
|
output module, contributed by sur5r. With 1.20.0, December is also the first
|
|
time since the bug hunt that we introduce other new features. It has been decided
|
|
that we carefully will add features in order to not affect the overall project
|
|
by these rare bugs. Still, the bug hunt is top priority, but we need to have more
|
|
data to analyze. At then end of December, it looked like the bug was found (a
|
|
race condition), but further confirmation from the field is required before
|
|
declaring victory. December also brings the initial development on <b>rsyslog v3</b>,
|
|
resulting in loadable input modules, now running on a separate thread each.</p><p>On
|
|
<b>January, 2nd 2008</b>, rsyslog 1.21.2 is re-released as rsyslog v2.0.0
|
|
stable. This is a major milestone as far as the stable build is concerned. v3 is
|
|
not yet officially announced. Other than the stable v2 build, v3 will not be
|
|
backwards compatibile (including missing compatibility to stock sysklogd) for
|
|
quite a while. Config file changes are required and some command line options do
|
|
no longer work due to the new design.</p><p>On <span style="font-weight: bold;">January, 31st 2008</span>
|
|
the new massively-multithreaded queue engine was released for the first
|
|
time. It was a major milestone, implementing a feature I dreamed of for
|
|
more than a year.</p><p>End of <span style="font-weight: bold;">February 2008</span>
|
|
saw the first note about RainerScript, a way to configure rsyslogd via
|
|
a script-language like configuration format. This effort evolved out of
|
|
the need to have complex expression support, which was also the first
|
|
use case. On February, 28th rsyslog 3.12.0 was released, the first
|
|
version to contain expression support. This also meant that rsyslog
|
|
from that date on supported all syslog-ng major features, but had a
|
|
number of major features exlusive to it. With 3.12.0, I consider
|
|
rsyslog fully superior to syslog-ng (except for platform support).</p><p>Be sure to visit Rainer's <a href="http://rgerhards.blogspot.com/">syslog blog</a>
|
|
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
|
|
<a href="http://www.rsyslog.com/PNphpBB2.phtml">rsyslog forums</a>.</p>
|
|
<h2>Some useful links</h2>
|
|
<ul>
|
|
<li><a href="http://www.rsyslog.com/Topic4.phtml">the rsyslog change log</a></li>
|
|
</ul>
|
|
</body></html> |