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
|
<html>
<head>
<title>rsyslog features</title>
</head>
<body>
<h1>RSyslog - Features</h1>
<p><b>This page lists both current features as well as those being considered
for future versions of rsyslog.</b> If you think a feature is missing, drop
<a href="mailto:rgerhards@adiscon.com">Rainer</a> a note. Rsyslog is a vital
project. Features are added each few days. If you would like to keep up of what
is going on, you can also subscribe to the <a href="http://lists.adiscon.net/mailman/listinfo/rsyslog">rsyslog mailing list</a>.
</p>
<h2>Current Features</h2>
<ul>
<li>native support for <a href="rsyslog_mysql.html">writing to MySQL databases</a><li>support for (plain) tcp
based syslog - much better reliability<li>support for sending and receiving
compressed syslog messages<li>support for receiving messages via
reliable <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">
RFC 3195</a> delivery<li>ability to generate file names (log targets)
dynamically, based on many different properties<li>control of log output format,
including ability to present channel and priority as visible log data<li>good timestamp format control; at a minimum, ISO 8601/RFC 3339
second-resolution UTC zone<li>ability to reformat message contents and work with substrings<li>support for
log files larger than 2gb<li>support for file size limitation and automatic
rollover command execution<li>support for running multiple rsyslogd
instances on a single machine<li>support for <a href="rsyslog_stunnel.html">
ssl-protected syslog</a> (via stunnel)<li>ability to filter on any part of
the message, not just facility and severity<li>support for discarding
messages based on filters<li>ability to execute shell scripts on received
messages<li>control of whether the local hostname or the hostname of the
origin of the data is shown as the hostname in the output<li>ability to
preserve the original hostname in NAT environments and relay chains
<li>ability to limit the allowed network senders<li>powerful BSD-style
hostname and program name blocks for easy multi-host support<li>
multi-threaded<li>very
experimental and volatile support for <a href="syslog-protocol.html">syslog-protocol</a>
compliant messages (it is volatile because standardization is currently
underway and this is a proof-of-concept implementation to aid this effort)<li>
experimental support for syslog-transport-tls based framing on syslog/tcp
connections<li>
a copy of klogd.c has been included under the name of rklogd for those Linux
systems that need one. So rsyslog is a full replacement for the sysklogd
package<li>
support for IPv6</ul>
<p> </p>
<h2>Upcoming Features</h2>
<p>The list below is something like a repository of ideas we'd like to
implement. Features on this list are typically NOT scheduled for immediate
inclusion. We maintain a
<a href="http://sourceforge.net/tracker/?group_id=123448&atid=696555">feature
request tracker at sourceforge.net</a>. This tracker has things typically within
reach of implementation. Users are encouraged to submit feature requests there
(or via our forums). If we like them but they look quite long-lived (aka "not
soon to be implemented"), they will possibly be migrated to this list here and
at some time moved back to the sourceforge tracker.</p>
<ul>
<li>create a plug-in-interface<li>implement native email-functionality in
selector (probably best done as a plug-in)<li>port it to more *nix variants
(eg AIX and HP UX) - this needs volunteers with access to those machines and
knowledge<li>provide an on-disk queue for syslog messages; should be
combined with reliable delivery to the next hop<li>support for native SSL enryption of plain tcp syslog sessions. This will
most probably happen based on syslog-transport-tls.<li>even more enhanced multi-threading,
with a message queue for each selector line (when implementing this, search
for CHECKMULTIQUEUE comments in the source - they already contain hints of
what to look at).<li>pcre filtering - maybe (depending on feedback) - simple regex already
partly added. So far, this seems sufficient so that there is no urgent<li>support for
<a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a>
as a sender - this is currently unlikely to happen, because there is no real
demand for it. Any work on RFC 3195 has been suspend until we see some real
interest in it. It is probably much better to use TCP-based syslog,
which is interoprable with a large number of applications.</ul>
<p>To see when each feature was added, see the
<a href="http://www.rsyslog.com/Topic4.phtml">rsyslog change log</a> (online
only).</p>
</body>
</html>
|
