1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
<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 Rainer Gerhards. It has
been forked from the <a href="http://www.infodrom.org/projects/sysklogd/">sysklogd standard package</a>.
The goal of the
rsyslog project is to provide a more configurable and reliable
syslog deamon while retaining drop-in replacement capabilities for 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. In fact, the
opposite is the case and we assume that for the time being the well-used
sysklogd package offers better program reliability than our
brand-new modifications to it.
</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 contains 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 here we are, 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.</p><p>
The next enhancement scheduled is support for the new syslog-protocol
internet draft format, not the least to see how easy/complicated it is
to implement. We already know that some subleties of syslog-protocol will
require at least one considerable architectural change to the syslogd
and this might delay things a little. Our immediate goal is to receive
feedback and get the bugs out of the current release. Only after that
we intend to advance the code and introduce new features.
</p><p>
The database support was included so that our web-based syslog interface
can 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.
</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.
<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>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>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>Be sure to visit Rainer's <a href="http://rgerhards.blogspot.com/">syslog block</a>
to get some more insight into the development of rsyslog and syslog in general.</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>
|
