summaryrefslogtreecommitdiffstats
path: root/doc/rsyslog_conf_basic_structure.html
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rsyslog_conf_basic_structure.html')
-rw-r--r--doc/rsyslog_conf_basic_structure.html103
1 files changed, 103 insertions, 0 deletions
diff --git a/doc/rsyslog_conf_basic_structure.html b/doc/rsyslog_conf_basic_structure.html
new file mode 100644
index 00000000..f5d4891a
--- /dev/null
+++ b/doc/rsyslog_conf_basic_structure.html
@@ -0,0 +1,103 @@
+<html><head><title>Basic Structure - rsyslog.conf</title></head>
+<body>
+<h1>Basic rsyslog.conf Structure</h1>
+<p>This is a part of the rsyslog.conf documentation.</p>
+<a href="rsyslog_conf.html">Back to rsyslog.conf manual</a>
+<p>Rsyslog supports three different types of configuration statements
+concurrently:
+<ul>
+<li><b>sysklogd</b> - this is the plain old format, thaught everywhere
+and still pretty useful for simple use cases. Note that some very
+few constructs are no longer supported because they are incompatible
+with newer features. These are mentioned in the compatibility docs.
+<li><b>legacy rsyslog</b> - these are statements that begin with a dollar
+sign. They set some configuration parameters and modify e.g. the way
+actions operate. This is the only format supported in pre-v6 versions of
+rsyslog. It is still fully supported in v6 and above. Note that some
+plugins and features may still only be available through legacy format
+(because plugins need to be explicitely upgraded to use the new style
+format, and this hasn't happened to all plugins).
+<li><b>RainerScript</b> - the new style format. This is the best and most
+precise format to be used for more complex cases. The rest of this page
+assumes RainerScript based rsyslog.conf.
+</ul>
+<p>The rsyslog.conf files consists of statements. For old style (sysklogd &amp; legacy
+rsyslog), lines do matter. For new style (RainerScript) line spacing is irrelevant.
+Most importantly, this means with new style actions and all other objects can split
+across lines as users want to.
+<h2>Comments</h2>
+<p>There are two types of comments:
+<ul>
+<li><b>#-Comments</b> - start with a hash sign (#) and run to the end of the line
+<li><b>C-style Comments</b> - start with /* and end with */, just like in the C
+programming language. They can be used to comment out multiple lines at one. Comment
+nesting is not supported, but #-Comments can be contained inside a C-style comment.
+</ul>
+
+<h2>Processing Order</h2>
+<p>Directives are processed from the top of rsyslog.conf to the bottom. Sequence
+matters. For example, if you stop processing of a message, obviously all statements
+after the stop statement are never evaluated.
+
+<h3>Flow Control Statements</h3>
+<ul>
+<li><b>if expr then ... else ...</b> - conditional execution
+<li><b>stop</b> - stops processing the current message
+<li><b>call</b> - calls a ruleset (just like a subroutine call)
+<li><b>continue</b> - a NOP, useful e.g. inside the then part of an if
+</ul>
+
+<h3>Data Manipulation Statements</h3>
+<ul>
+<li><b>set</b> - <a href="http://www.rsyslog.com/how-to-set-variables-in-rsyslog-v7/">sets</a>
+a user variable
+<li><b>unset</b> - deletes a previously set user variable
+</ul>
+
+<h2>Inputs</h2>
+<p>Every input requires an input module to be loaded and a listener defined for it.
+Full details can be found inside the <a href="rsyslog_conf_modules.html">rsyslog
+modules</a> documentation. Once loaded, inputs are defined via the
+<b>input()</b> object.
+
+<h2>Outputs</h2>
+<p>Outputs are also called "actions". A small set of actions is pre-loaded (like
+the output file writer, which is used in almost every rsyslog.conf), others must
+be loaded just like inputs.
+<p>An action is invoked via the <b>action(type="type" ...)</b> object. Type is
+mandatory and must contain the name of the plugin to be called (e.g. "omfile" or
+"ommongodb"). Other paramters may be present. Their type and use depends on
+the output plugin in question.
+
+<h2>Rulesets and Rules</h2>
+<p>Rulesets and rules form the basis of rsyslog processing. In short, a rule
+is a way how rsyslog shall process a specific message. Usually, there is a type
+of filter (if-statement) in front of the rule. Complex nesting of rules is possible,
+much like in a programming language.
+<p>Rulesets are containers for rules. A single ruleset can contain many rules. In
+the programming language analogy, one may think of a ruleset like being a program.
+A ruleset can be "bound" (assigned) to a specific input. In the analogy, this means that when
+a message comes in via that input, the "program" (ruleset) bound to it will be executed
+(but not any other!).
+<p>There is detail documentation available for
+<a href="multi_ruleset.html">rsyslog rulesets</a>.
+<p>For quick reference, rulesets are defined as follows:
+<pre>
+ruleset(name="rulesetname") {
+ action(type="omfile" file="/path/to/file")
+ action(type="..." ...)
+ /* and so on... */
+}
+</pre>
+
+<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-2013 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>
+