I do what David shows just differently. I check the $fromhost-ip after
sending everything to the log repository. In my setup, I send endpoint
logs to a single active/passive HA cluster then ship to the CLR. You
could probably deploy an action along with a stop rule in another config
file for each external host that you wanted to send to. Here is a simple
example of what I am doing. Granted, I am not doing encryption yet but
the idea is still generally the same. I also cannot say exactly what
version supports what syntax but the version used on my aggregation
nodes and CLR node is v8.7.
#### Inputs ####
input(type="imtcp" port="514") # accept connection on port tcp 514
input(type="imudp" port="514") # accept connection on port udp 514
#### RULES for where to send Log Files ####
# send everything to central log store
action(type="omfwd"
target="server.domain.tld"
port="514"
protocol="tcp"
queue.spoolDirectory="/var/spool/rsyslog"
queue.filename="wait_queue"
queue.size="1000000"
queue.type="LinkedList"
)
# stop processing rules if not from localhost
if $fromhost-ip != "127.0.0.1" then {
stop
}
# sort the locally generated logs into standard files
#kern etc, etc.....
On 02/04/2015 08:38 PM, David Lang wrote:
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.
_______________________________________________
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.
