/usr/share/doc/rsyslog-doc/html/rsyslog_conf_basic_structure.html is in rsyslog-doc 7.4.4-1ubuntu2.3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 | <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 & 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 © 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>
|