summaryrefslogtreecommitdiffstats
path: root/doc/features.html
blob: 2899cd767933c3d6ed2e83f3327806f9df872a7c (plain)
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
<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>
	native support for writing to Postgres databases<li>support for (plain) tcp 
	based syslog - much better reliability<li>support for sending and receiving 
	compressed syslog messages<li>ability to configure backup syslog/database 
	servers - if the primary fails, control is switched to a prioritized list of 
	backups<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 and directories (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>ability to use regular 
	expressions in filters<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 (<a href="http://rgerhards.blogspot.com/2007/08/why-is-rsyslog-multi-threaded-and-is-it.html">is 
	this important? why?</a>)<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<li>
	ability to control repeated line reduction (&quot;last message repeated n times&quot;) 
	on a per selector-line basis<li>
	supports sub-configuration files, which can be automatically read from 
	directories. Includes are specified in the main configuration file<li>
	supports multiple actions per selector/filter condition<li>
	MySQL and Postgres SQL functionality as a dynamically loadable plug-in<li>
	support for GSS-API<li>
	modular design for outputs - easily extensible</ul>
<p>&nbsp;</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 &quot;not 
soon to be implemented&quot;), 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 - we are very close to this. A neat interface is 
	already used internally for output modules and the MySQL module already 
	works as a plug-in. However, no interface definition is yet formally 
	published.<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 action (when implementing this, search 
	for CHECKMULTIQUEUE comments in the source - they already contain hints of 
	what to look at). Some detail information on this can already be found in
	<a href="http://rgerhards.blogspot.com/2007/08/syslog-worker-pools-future-hardware-and.html">
	Rainer's blog</a>.<li>pcre filtering - maybe (depending on feedback)&nbsp; - simple regex already 
	partly added. So far, this seems sufficient so that there is no urgent need 
	to do pcre<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.&nbsp; 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>.</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>