[rsyslog-notify] Forum Thread: Re: Rsyslog logging using variables - (Mode 'reply')

[noreply at adiscon.com]

User: dlang 
Forumlink: http://kb.monitorware.com/viewtopic.php?p=25925#p25925

Message: 
----------
trying to configure rsyslog with the syslog-ng model is going to lead to a
config file that is confusing for both rsyslog and syslog-ng people

you may be able to do something by defining lots of rulesets with the
filters in the rulesets.

But with rsyslog you CANNOT define all the inputs, then all the filters,
then all the outputs, then all the relations between them, it just doesn't
work that way.

With rsyslog, you define all your inputs. The logs that arrive via the
inputs go into the main queue (unless you specify on an input that they go
to a specific ruleset instead)

If you define an input to be tied to a specific ruleset, then only the
rules in that ruleset will apply to those logs. This is useful for cases
where what you do with logs from one input are very different than what you
do with logs from other inputs.

For Example:

read a file and send everything in that file to one or more destinations,
but nothing else goes to those destinations is a perfect fit for a ruleset
tied to an input.

processing logs that arrive from a remote host differently than logs
generated locally is a perfect use of a ruleset tied to the remote inputs.

you can define additional rulesets, and rulesets can be called as the
result of filters (in which case only the logs that match the filters will
be processed by that ruleset). Think of them as subroutines.

rulesets can also be useful as a boundry to control queues. Too many queues
waste resources, and sometimes putting a queue on a ruleset instead of on
each action is a big win.

Outputs are generally fixed, but there are cases where you can use
templates (such as dynafile filename templates) to decide what file to but
the logs in based on the contents of the log message.


some of what you are trying to do does look like dynafile templates would
help

for example, you have a lot of destinations that have facility in their
name, you could define one action with a dynafile template that will write
to all of those files (although you would need to standardize the filenames
a bit more)


now, looking at your ruleset, everything you do is based on all sources, so
you don't care where the log came from. As a result, you may not need
rulesets

so let's look at your actual rules (ignoring the boilerplate that defines
the inputs)

[quote:36hkpvqy][code:36hkpvqy]
    # Send all logs remotely
    log {
            source(s_all);
            destination(dr_all);
    };
[/code:36hkpvqy][/quote:36hkpvqy]
so for this, you just need

@@syslog.example.com

[quote:36hkpvqy][code:36hkpvqy]
    # Send specific logs to local files
    log {
            source(s_all);
            filter(f_auth);
            destination(df_auth);
    };

    log {
            source(s_all);
            filter(f_syslog);
            destination(df_syslog);
    };
[/code:36hkpvqy][/quote:36hkpvqy]

auth.*  {
  /var/log/auth.log
  stop
}

# throw away all local2 logs so that nothing else will see them
local2.* stop
/var/log/syslog
[quote:36hkpvqy][code:36hkpvqy]

    log {
            source(s_all);
            filter(f_cron);
            destination(df_cron);
    };
[/code:36hkpvqy][/quote:36hkpvqy]

cron.* /var/log/cron.log

[quote:36hkpvqy][code:36hkpvqy]
    log {
            source(s_all);
            filter(f_daemon);
            destination(df_daemon);
    };
[/code:36hkpvqy][/quote:36hkpvqy]
daemon.* /var/log/daemon.log

[quote:36hkpvqy][code:36hkpvqy]

    log {
            source(s_all);
            filter(f_kern);
            destination(df_kern);
    };
[/code:36hkpvqy][/quote:36hkpvqy]

kern.* /var/log/kern.log

[quote:36hkpvqy][code:36hkpvqy]

    log {
            source(s_all);
            filter(f_mail);
            filter(f_at_least_info);
            destination(df_facility_dot_info);
    };
[/code:36hkpvqy][/quote:36hkpvqy]

mail.info  /var/log/mail.info

[quote:36hkpvqy][code:36hkpvqy]
    log {
            source(s_all);
            filter(f_news);
            filter(f_at_least_crit);
            destination(df_news_dot_crit);
    };
[/code:36hkpvqy][/quote:36hkpvqy]

news.crit /var/log/news/news.crit
# or to have this written as user news:

news.crit action(type="omfile" file="/var/log/news/news.crit" user="news")


so stripping away the quotes, your ruleset could be:

#log all auth and make it so they don't show up in the catchall file
auth.*  {
  /var/log/auth.log
  stop
}
# throw away all local2 logs so that nothing else will see them
local2.* stop
#log everything but local2 and auth to the catchall file
/var/log/syslog
cron.* /var/log/cron.log
daemon.* /var/log/daemon.log
kern.* /var/log/kern.log
mail.info  /var/log/mail.info
news.crit action(type="omfile" file="/var/log/news/news.crit" user="news")


now, this could be 'simplified' further by

$template facilityfiles,"/var/log/%facility-text%.log"
#log all auth and make it so they don't show up in the catchall file
auth.*  {
  ?facilityfiles
  stop
}
# throw away all local2 logs so that nothing else will see them
local2.* stop
#log everything but local2 and auth to the catchall file
/var/log/syslog
if $facility-text == ["cron", "daemon", "kern"] then ?facilityfiles
mail.info  /var/log/mail.info
news.crit action(type="omfile" file="/var/log/news/news.crit" user="news")