Hello Michael:
Welcome to using sec.
In message <DM2PR0601MB13576870EB41000D0BC35126F95F0@DM2PR0601MB1357.namprd06.p
rod.outlook.com>,
Michael Hare writes:
>Ideally, at sec termination I would like a summary of how many times
>each rule was called. I'm mainly looking for dead/unused rules in my
>config.
Note that a rule can be unused only because there was no matching
event for it during that run of SEC. It doesn't mean the rule will
never be matched.
However that said, if you read the SIGNALS part of the man page, you
will see you can generate a dump file that lists along with each rule
the number of times it was executed. E.G.
Rule usage statistics:
============================================================
Statistics for the rules from 1.sr
(loaded at Sat Jul 4 15:08:46 2009)
------------------------------------------------------------
Rule 1 at line 1 (to skip1) has matched 0 events
Rule 2 at line 8 (emulate single with suppress. 1 minute suppress trigger)
has matched 5 events
Rule 3 at line 15 (emulate single with suppress. 1 minute suppress munch) has
matched 3 events
Rule 4 at line 22 (no skip or suppress seen.) has matched 0 events
Rule 5 at line 31 (first rule after skip1) has matched 0 events
Note that the dump file (/tmp/sec.dump or the argument to --dump) must
not exist before triggering the dump. The dump command will never
overwrite a file.
>I searched the mailing list for 'dead' and 'unused' and came up
>empty. Admittedly I have perused the intimidatingly long manpage but
>haven't read it front to back.
Usually people just grab the data at runtime using:
kill -USR1 <sec pid>
You may want to create a calendar rule with an action that calls
shellcmd to remove the dump file and send a kill -USR1 to the sec
process to keep a more or less up to date dump file (but having it
automatically updated may interfere with using it to debug sec).
I was going to suggest using --intevents and a rule that matches
SEC_SHUTDOWN to send a kill -USR1 to the SEC process, but I am not
sure what happens to signal handling when SEC is planning to exit.
Risto may be able to tell you what will happen in this case.
>I've seen rule number mentioned in 'EVENT CORRELATION OPERATIONS'
>section of the manpage with respect to event correlation, but I'm not
>really using "type=SingleWithThreshold" nor am I quite sure if the
>rule number is a variable I can easily get to.
The rule number and rule description are shown in the dump file. Note
rule numbers are per config/rule file. There is no global "rule 7"
there can be a rule 7 in each file specified with --conf.
>Any pointers on how best to achieve? The only thing that came to my
>mind [as of yet untried, because I'm hoping for something more
>elegant] would be for each rule to have an action that appends the
>current rule number to a file for me to process outside of sec.
You can also use a write action. Something like:
write /tmp/stats fired rule %s
(and change the rules from suppress rules to single rules as I don't
think suppress rule have actions). Where %s is replaced with the
description of the rule.
I would suggest just using the dump file.
Also besides looking for dead rules, if you order your rules with the
most used rules first in the config file, you will get better
performance.
Every event is evaluated by every rule in the config file(s) (assuming
you aren't using jumps). So the fewer evaluations before a match
occurs, the better the performance. If you put the most used rules
first, the average number of evaluations that an event has to go
though before it gets matched is reduced. Fewer evaluations, fewer cpu
cycles taken.
SEC (currently) doesn't provide stats on the number of times a rule
was reached (i.e. evaluated an event). It only reports the number of
times it matched an event. One of these days I have to finish my
testing of the code that adds evaluation stats to each rule.
Hope this gets you going in the right direction.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
