Menu

$IncludeConfig is Your Friend

If you have a large rsyslog environment with multiple inputs, multiple modules, lists of templates and a slew of rules and rulesets, you’ll want to keep it all organized and accessible. Here’s a few pointers for using $IncludeConfig to keep your configuration as simple, easy to maintain and efficient as possible.

Organize Your Configs

The primary and most popular use of $IncludeConfig is to break up your configuration in to logical pieces (i.e. files) and for organizing those pieces.

The $IncludeConfig directive allows you to insert configuration directives from other files, parsing them and including their content of the current configuration set. Basically – if you find yourself copying and pasting configuration blocks to multiple different spots, you probably could use $IncludeConfig. My main rsyslogd.conf file contains only:

Then within those directories all configuration files are prefixed with a two digit number, i.e.:

rules/10_udprules.conf
rules/20_tcprules.conf
rules/30_relprules.conf

This allows me fine-grained control over the order in which rsyslog parses and evaluates its configuration. In day-to-day operations, the order in which the configuration is loaded isn’t critical, but if you ever have to run rsyslog in debug mode (and you will) this will make a huge difference in making the debug logs more readable.

This method also allows you to quickly update, add and delete configuration elements with minimal risk. Need another input? Just drop another .conf file in the inputs directory and reload. shut And if you fat-finger that new config and it doesn’t work, the chances of that affecting any other working element are minimized.

Enforce Global Rules Across Multiple Rulesets

The setting up of rules and rulesets is often where configurations become obfuscated and unnecessarily complex. So you have multiple inputs and as such you have multiple rulesets – UDP rulesets, imfile rulesets, TCP rulesets… Each is specific to its own input and for the most part they are autonomous from eachother. But what if you want to include a rule that should apply to all rulesets? Say you have a blacklist of hosts you don’t want to accept messages from on any input, or if you want to route all *.crit messages to your alerting system regardless of where they come from? With each input tied to a ruleset you may assume that these types of rules would have to be copied in to each ruleset. Not so – $IncludeConfig will do that for you. Just put these global rules – directives you want to apply to all rulesets – in a file: