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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>
<p><span style="font-weight: bold;">A better
structured feature list is now contained in our </span><a style="font-weight: bold;" href="rsyslog_ng_comparison.html">rsyslog
vs. syslog-ng comparison</a><span style="font-weight: bold;">.
</span>Probably that page will replace this one in the
future.
</p>
<h2>Current Features</h2>
<ul>
<li>native support for <a href="rsyslog_mysql.html">writing
to MySQL databases</a></li>
<li> native support for writing to Postgres databases</li>
<li>direct support for Firebird/Interbase,
OpenTDS (MS SQL, Sybase), SQLLite, Ingres, Oracle, and mSQL via libdbi,
a database abstraction layer (almost as good as native)</li><li>native support for <a href="ommail.html">sending mail messages</a> (first seen in 3.17.0)</li>
<li>support for (plain) tcp based syslog - much better
reliability</li>
<li>support for sending and receiving compressed syslog messages</li>
<li>support for on-demand on-disk spooling of messages that can
not be processed fast enough (a great feature for <a href="rsyslog_high_database_rate.html">writing massive
amounts of syslog messages to a database</a>)</li><li>support for selectively <a href="http://wiki.rsyslog.com/index.php/OffPeakHours">processing messages only during specific timeframes</a> and spooling them to disk otherwise</li>
<li>ability to monitor text files and convert their contents
into syslog messages (one per line)</li>
<li>ability to configure backup syslog/database servers - if
the primary fails, control is switched to a prioritized list of backups</li>
<li>support for receiving messages via reliable <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">
RFC 3195</a> delivery (a bit clumpsy to build right now...)</li>
<li>ability to generate file names and directories (log
targets) dynamically, based on many different properties</li>
<li>control of log output format, including ability to present
channel and priority as visible log data</li>
<li>good timestamp format control; at a minimum, ISO 8601/RFC
3339 second-resolution UTC zone</li>
<li>ability to reformat message contents and work with
substrings</li>
<li>support for log files larger than 2gb</li>
<li>support for file size limitation and automatic rollover
command execution</li>
<li>support for running multiple rsyslogd instances on a single
machine</li>
<li>support for <a href="rsyslog_stunnel.html">
ssl-protected syslog</a> (via stunnel)</li>
<li>ability to filter on any part of the message, not just
facility and severity</li>
<li>ability to use regular expressions in filters</li>
<li>support for discarding messages based on filters</li>
<li>ability to execute shell scripts on received messages</li>
<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>
<li>ability to preserve the original hostname in NAT
environments and relay chains </li>
<li>ability to limit the allowed network senders</li>
<li>powerful BSD-style hostname and program name blocks for
easy multi-host support</li>
<li> massively multi-threaded with dynamic work thread pools
that start up and shut themselves down on an as-needed basis (great for
high log volume on multicore machines)</li>
<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>
<li> experimental support for syslog-transport-tls based
framing on syslog/tcp connections</li>
<li> the sysklogd's klogd functionality is implemented as the <i>imklog</i>
input plug-in. So rsyslog is a full replacement for the sysklogd package</li>
<li> support for IPv6</li>
<li> ability to control repeated line reduction ("last message
repeated n times") on a per selector-line basis</li>
<li> supports sub-configuration files, which can be
automatically read from directories. Includes are specified in the main
configuration file</li>
<li> supports multiple actions per selector/filter condition</li>
<li> MySQL and Postgres SQL functionality as a dynamically
loadable plug-in</li>
<li> modular design for inputs and outputs - easily extensible
via custom plugins</li>
<li> an easy-to-write to plugin interface</li>
<li> ability to send SNMP trap messages</li>
<li>support for arbitrary complex boolean, string and
arithmetic expressions in message filters</li>
</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://bugzilla.adiscon.com/rsyslog-feature.html">feature
request tracker at our bugzilla</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>implement native email-functionality in selector (probably
best done as a plug-in)</li>
<li>port it to more *nix variants (eg AIX and HP UX) - this
needs volunteers with access to those machines and knowledge </li>
<li>support for native SSL enryption of plain tcp syslog
sessions. This will most probably happen based on syslog-transport-tls.</li>
<li>pcre filtering - maybe (depending on feedback) -
simple regex already partly added. So far, this seems sufficient so
that there is no urgent need to do pcre</li>
<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 interoperable with a
large number of applications. You may also read my blog post on the
future of liblogging, which contains interesting information about the <a href="http://rgerhards.blogspot.com/2007/09/where-is-liblogging-heading-to.html">
future of RFC 3195 in rsyslog</a>.</li>
</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>
|
