summaryrefslogtreecommitdiffstats
path: root/doc/rsyslog_conf_modules.html
blob: b721c9358177cc4c1280d1a21fbe1074d768b6a8 (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
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Modules - rsyslog.conf</title></head>
<body>
<p>This is a part of the rsyslog.conf documentation.</p>
<a href="rsyslog_conf.html">Back to rsyslog.conf manual</a>
<h1>Modules</h1>
<p>Rsyslog has a modular design. This enables functionality to be
dynamically loaded from modules, which may also be written by any
third party. Rsyslog itself offers all non-core functionality as
modules. Consequently, there is a growing
number of modules. Here is the entry point to their documentation and
what they do (list is currently not complete)</p>
<p>Please note that each module provides configuration
directives, which are NOT necessarily being listed below. Also
remember, that a modules configuration directive (and functionality) is
only available if it has been loaded (using $ModLoad).</p>
<p>It is relatively easy to write a rsyslog module. <b>If none of the provided
modules solve your need, you may consider writing one or have one written
for you by
<a href="http://www.rsyslog.com/professional-services">Adiscon's professional services for rsyslog</a>
</b>(this often is a very cost-effective and efficient way of getting what you need).
<p>There exist different classes of loadable modules:
<ul>
<li><a href="rsyslog_conf_modules.html#im">Input Modules</a>
<li><a href="rsyslog_conf_modules.html#om">Output Modules</a>
<li><a href="rsyslog_conf_modules.html#pm">Parser Modules</a>
<li><a href="rsyslog_conf_modules.html#mm">Message Modification Modules</a>
<li><a href="rsyslog_conf_modules.html#lm">Library Modules</a>
</ul>

<a name"im"></a><h2>Input Modules</h2>
<p>Input modules are used to gather messages from various sources. They interface
to message generators.
<ul>
<li><a href="imfile.html">imfile</a> -&nbsp; input module for text files</li>
<li><a href="imrelp.html">imrelp</a> - RELP input module</li>
<li>imudp - udp syslog message input</li>
<li><a href="imtcp.html">imtcp</a> - input plugin for plain tcp syslog</li>
<li><a href="imgssapi.html">imgssapi</a> - input plugin for plain tcp and GSS-enabled syslog</li>
<li>immark - support for mark messages</li>
<li><a href="imklog.html">imklog</a> - kernel logging</li>
<li><a href="imuxsock.html">imuxsock</a> - unix sockets, including the system log socket</li>
<li><a href="imsolaris.html">imsolaris</a> - input for the Sun Solaris system log source</li>
<li><a href="im3195.html">im3195</a> - accepts syslog messages via RFC 3195</li>
</ul>

<a name"om"></a><h2>Output Modules</h2>
<p>Output modules process messages. With them, message formats can be transformed
and messages be transmitted to various different targets.
<ul>
<li><a href="omsnmp.html">omsnmp</a> - SNMP trap output module</li>
<li><a href="omstdout.html">omtdout</a> - stdout output module (mainly a test tool)</li>
<li><a href="omrelp.html">omrelp</a> - RELP output module</li>
<li><a href="omruleset.html">omruleset</a> - forward message to another ruleset</li>
<li>omgssapi - output module for GSS-enabled syslog</li>
<li><a href="ommysql.html">ommysql</a> - output module for MySQL</li>
<li>ompgsql - output module for PostgreSQL</li>
<li><a href="omlibdbi.html">omlibdbi</a> -
generic database output module (Firebird/Interbase, MS SQL, Sybase,
SQLLite, Ingres, Oracle, mSQL)</li>
<li><a href="ommail.html">ommail</a> -
permits rsyslog to alert folks by mail if something important happens</li>
<li><a href="omoracle.html">omoracle</a> - output module for Oracle (native OCI interface)</li>
<li><a href="omudpspoof.html">omudpspoof</a> - output module sending UDP syslog messages with a spoofed address</li>
</ul>

<a name="pm"></a><h2>Parser Modules</h2>
<p>Parser modules are used to parse message content, once the message has been
received. They can be used to process custom message formats or invalidly formatted
messages. For details, please see the <a href="messageparser.html">rsyslog
message parser documentation</a>.
<p>The current modules are currently provided as part of rsyslog:
<ul>
<li>pmrfc5424 - parses RFC5424-formatted messages (the new syslog standard)
<li>pmrfc3164 - the traditional/legacy syslog parser
</ul>

<a name="mm"></a><h2>Message Modification Modules</h2>
<p>Message modification modules are used to change the content of messages being processed.
They can be implemented using either the output module or the parser module interface.
From the rsyslog core's point of view, they actually are output or parser modules, it is their
implementation that makes them special.
<p>Currently, there do not exist any such modules, but could be written with
the methods the engine provides. They could be used, for example, to:
<ul>
<li>anonymize message content
<li>add dynamically computed content to message (fields)
</ul>

<a name="lm"></a><h2>Library Modules</h2>
<p>Library modules provide dynamically loadable functionality for parts of rsyslog,
most often for other loadable modules. They can not be user-configured and are loaded
automatically by some components. They are just mentioned so that error messages that
point to library moduls can be understood. No module list is provided.

<h2>Where are the modules integrated into the Message Flow?</h2>
<p>Depending on their module type, modules may access and/or modify messages at
various stages during rsyslog's processing. Note that only the "core type" (e.g. input,
output) but not any type derived from it (message modification module) specifies when
a module is called.
<p>The simplified workflow is as follows:
<p align="center">
<img src="module_workflow.png" alt"rsyslog: loadable modules and message flow">
<p>As can be seen, messages are received by input modules, then passed to one or many
parser modules, which generate the in-memory representation of the message and may
also modify the message itself. The, the internal representation is passed to
output modules, which may output a message and (with the interfaces newly introduced
in v5) may also modify messageo object content.
<p>Note that the actual flow is much more complex and depends a lot on queue and
filter settings. This graphic above is a high-level message flow diagram.

<p>[<a href="manual.html">manual index</a>]
[<a href="rsyslog_conf.html">rsyslog.conf</a>]
[<a href="http://www.rsyslog.com/">rsyslog site</a>]</p>
<p><font size="2">This documentation is part of the
<a href="http://www.rsyslog.com/">rsyslog</a> project.<br>
Copyright &copy; 2008, 2009 by <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a> and
<a href="http://www.adiscon.com/">Adiscon</a>. Released under the GNU GPL
version 3 or higher.</font></p>
</body>
</html>