[rsyslog-notify] Forum Thread: Re: Rsyslog logging using variables - (Mode 'reply')
noreply at adiscon.com
noreply at adiscon.com
Sat Sep 19 00:26:48 CEST 2015
User: dlang
Forumlink: http://kb.monitorware.com/viewtopic.php?p=25937#p25937
Message:
----------
[quote="Jzeolla":2mlo04vk]First of all - thanks a ton for the detailed
information and analysis.
The above example that I provided was a simplified and truncated version of
my actual config where I tried to display every use case. However, I
didn't portray that the logic for ignore_this is more complicated than just
ignore everything to a facility because I didn't think it was relevant at
the time. The goal is to have a 'custom_write' which includes a certain
facility (such as facility(local4)), and then have ignore_this contain
specifics to ignore, such as (((facility(user) and priority(info) and
program(audispd)) or facility(local2)) and not filter(custom_write)). The
goal is to always write something to disk if it matches custom_write, even
if it also matches ignore_this, so the default is the more conservative
write it to disk.
[/quote:2mlo04vk]
well, if you can use a dynafile template for your output, you can nest a
ruleset call that includes your 'ignore this' filter and the output inside
your other logic
unfortunately your simplified explanation leads to simplified answers :-)
[quote]
I already have a separate config file which handles remote input and ties
different input methods to separate rulesets and has lengthy rainerscript
parsing which is working well - my focus here is to use 50-default.conf to
handle local (i.e. 'client') syslog appropriately. What I mean by client
is that every server in my environment (including my rsyslog server) will
get the 50-default.conf file and its local logs will be a client of our
logging infrastructure and still send logs to the load balanced aggregation
layer. This is because we do a lot of parsing and selective forwarding
that needs to be applied even to logs of the rsyslog server or rsyslogd (as
opposed to just writing it to the correct file locally on the rsyslog
server where other remote logs are stored).
I'm interested in your comment about queueing per ruleset instead of per
action. On my server I currently have one queue per action, but after each
action I have stop, so it would never hit more than one action in a
ruleset. That makes me think that it may be more efficient to have one
queue for each ruleset, reducing the number of queues from around 12 to 2
or 3. After briefly looking into this
([url=http://comments.gmane.org/gmane.comp.sysutils.rsyslog/8770:2mlo04vk]relevant
link[/url:2mlo04vk]), can I simply migrate my queue settings to the ruleset
to it looks like:
[code:2mlo04vk]ruleset(name="nonsensitive" queue.type="LinkedList"
queue.filename="queue_nonsensitive" queue.saveonshutdown="on"
queue.discardseverity="7" queue.discardmark="100000"
queue.highwatermark="75000" queue.size="102400"
queue.maxfilesize="1g" queue.maxdiskspace="100g") {
# Insert logic and actions here
}[/code:2mlo04vk]
remember that you only want to put a queu on an action that is likely to
take a long time or may block causing other things to stop processing.
putting a queue on everything eats up a lot of memory and causes rsyslog to
actually slow down.
More information about the rsyslog-notify
mailing list