racluster request
carter at qosient.com
carter at qosient.com
Thu Oct 26 07:31:32 EDT 2006
I like this idea, but using this kind of strategy can get pretty complicated.
How about multiple sections in the racluster.conf file, with separate rules and outputs? Each record is processed against all the sections?
I also see how a simple fall through logic can be too simple, but to do any other approach really begs for a programatic like strategy, with "if then" like statements. If your interested in scoping this type of approach, we can do a compiler for it!!!
Carter
Carter
Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
-----Original Message-----
From: "Denton, Rick" <rick.denton at cybertrust.com>
Date: Thu, 26 Oct 2006 11:26:05
To:<argus-info at lists.andrew.cmu.edu>
Subject: [ARGUS] racluster request
would it be feasible to prehaps add a flag to the racluster config lines
to flag them as final?
with racluster and ragator the first matching rule matched and
processing stopped at that rule.. what i would_really_ like is to be
able to control more specifically which aggregates contained which data
by allowing multiple entries in the racluster.conf table to match...
a simplistic way to do this would be to allow for a 'final' flag on an
entry to say whether or not to stop processing yet.. this doesn't
completely do it but provides somewhat more control..
for example to aggregate per service aswell as per protocol yielding
totals for both in a single run of racluster..
this would save me from having to make multiple passes over the data
which wuold save a_lot_ of processing time.. this coupled with the more
flexible filter="" matching on racluster over ragator would also reduce
a stage of prefiltering and reduce the processing time significantly
over filtering seemingly arbitrarily assigned address ranges and
counting of the approx 80gb of heavily compressed raw argus data a month
:/
More information about the argus
mailing list