On Wed, 4 Feb 2015, Amy Rich wrote:
david> why are you trying to split them? all logs get processed by all rules
by
david> default, so if the aggregators forward their logs, they will also
forward logs
david> they receive.
The config files are being pushed out by puppet, so keeping the files
themselves separate makes life much easier because we can use two different
templates. We also don't *want* all logs processed by all rules, since we
don't want the logs coming from the client to be logged on the disk of the
aggregation server. That was the first iteration I tried and would be a great
way to fill up the local disks on the aggregators with information we don't
want to keep there.
Ok, I wasn't even referring to having them in different files, but I can
understand wanting to do that if they are being managed independently. Although,
I would ask, other than the destination to deliver logs to, is there really a
difference between the config on the relays and the config on the rest of the
systems generating logs? I think one config would work for everything if you
wanted it to.
In terms of splitting local vs remote traffic, there are two approaches that you
can take.
1. you can have a test to see if the logs are from the local server or not
if $fromhost-ip == "127.0.0.1" then {
things to do with local logs
}
send to remote server
Or you can create separate rulesets and bind rulesets to individual inputs. In
the legacy syntax, ruleset configs are very hard to understand, in the new
syntax they are trivial
ruleset() {
some rules
}
david> Using the legacy format, you are not achieving what you think you are.
You are creating a large and
david> complex queue to write to a local file and will completely stall if
the remote system is down.
I took the queue configuration lines from the hosted syslog site's
suggestions page.
I'm not familiar with that site. The queue itself is probably fine, the problem
is that it only applies to the next action that takes place, in this case the
write to a local file.
In the new syntax, queue parameters are set explicitly as part of something else
action(some stuff queue.type='fixedarray' queue.size='5000' etc)
or
ruleset(some stuff queue.type='fixedarray' queue.size='5000' etc){
in this case the queue is used for the entire set of rules, not just for one
}
david> All of this would be obvious with the new style config.
Okay, I'm not at all clear on how to write what I need in the new style
config. Suggestions on how to translate?
the documentation on the rsyslog.com website, which also ships with each rsyslog
package has lots of details and examples.
For simple things (write to a file, forward to a remote server without a queue)
the legacy syntax is simpler and more obvious. but if you are dealing with
rulesets and defining queues, the new syntax will make the result much clearer.
The good thing is that you can mix and match for different actions, so you can
have some defined as action() and others as /var/log/messages or @ip style. You
just can't mix parameters (including queue options) of different styles for the
same action.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
