2012/12/6 John P. Rouillard <rou...@cs.umb.edu>:
>
> 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.
That's true - since in stable environments dump files are probably not
frequently created, some extra work in this function will have no
significance, compared to the extra CPU consumption spent for *every*
input line. Also, in dump creation function a lot of work has to be
done anyway, since almost all internal data structures have to be
scanned, and their content written to an external file.
>
> 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...").
The text can be of course shortened, although it would win 7 bytes
which probably makes little difference in output. Fortunately, the
most important information is in the beginning in the line anyway.
kind regards,
risto
> --
> -- 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
------------------------------------------------------------------------------
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
