In message <50c06562.8030...@seb.ee>,
Risto Vaarandi writes:
>On 12/05/2012 05:17 AM, John P. Rouillard wrote:
>> Currently the output of a state dump (generated with a kill -USR1)
>> looks like:
>>
>> Rule 1 at line 31 (Clear EVENT_PROCESSED) has matched 6431597 events
>> Rule 2 at line 51 (Skip all processing for slapd) has matched 14126179 events
>> Rule 3 at line 72 (Dispatch firewall accept lines) has matched 483828 events
>> Rule 4 at line 95 (Dispatch firewall rule lines) has matched 167890 events
>> [...]>>
>> I often find myself comparing counts, or summing counts etc. and I am
>> wondering if other people would also find this format better:
>>
>> Rule 1 at line 31 matched 6431597 events (Clear EVENT_PROCESSED)
>> Rule 2 at line 51 matched 14126179 events (Skip all processing for slapd)
>> Rule 3 at line 72 matched 483828 events (Dispatch firewall accept lines)
>> [...]
>> With this layout it is easier to see that rule 2 is hit the most and
>> rule 6 the least. Plus I can use awk/perl to pull field 7 and sum
>> them. This will take a little extra processing due to the right
>> aligned matched events count, but I don't think this processing would
>> be excessively burdensome.
>
>Currently I've changed the code and have two versions.
>For the first version the output is looking like this:
>
>Rule 1 at line 1 has matched 0 events (ssh event)
>Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
>Rule 3 at line 18 has matched 0 events ($:{SSH2:time}: SSH login event
>for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
>
>Nevertheless, for making the "matched" and "events" strings aligned
>across all rows, an extra preliminary loop over the ruleset would be
>required, which would establish the maximum length of the line number
>and match counter. This extra loop is included in the second version:
>
>Rule 1 at line 1 has matched 30 events (ssh event)
>Rule 2 at line 10 has matched 0 events (SSH login failure for $:{SSH:3})
>Rule 3 at line 18 has matched 30 events ($:{SSH2:time}: SSH login event
>for user $:{SSH2:3} from IP $:{SSH:4} type $:{SSH:2})
>
>Which one would you prefer? The second one is easier to grasp for a
>human eye, but some extra CPU time has to be spent.
I think I prefer the second. More like a table and easier to scan
(ignoring the line wrap I assume was added by the mailer). To cut
down on processing time, would it be worthwhile to:
Cache the max line number (and max rule number) for the rule set
when the ruleset is read in. That way the processing is done at
load time not while you are up and running (yes I am assuming
dynamic reloads will be fewer than status dumps).
Perhaps some similar cache could be done for the match counter to
record the maximum number of hits. But I don't like this as much
as it adds processing steps to the main event processing loop.
Also, to get more info on a line I wonder if the "at" and "has" are
required. Is:
Rule 1 line 1 matched 30 events (ssh event)
as readable? (maybe "Rule 1, line...").
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
