In message <[EMAIL PROTECTED]>,
ScottO writes:
>On Wed, Apr 9, 2008 at 11:44 AM, John P. Rouillard <[EMAIL PROTECTED]>
>wrote:
>> I suspect that handling correlations in progress would also be just a
>> problematic. E.G. what so you do with a partly done PairWithWindow?
>> If the window expired while sec was down do you trigger it's action as
>> though pattern2 hadn't been seen?
>>
>>
>That's a good point. The main reason I was asking, was I have a bunch of
>disk-related rules tucked in a file for instance. One example, is a
>SingleWith2Thresholds, which works well when it notices a disk failing, it
>sends an email, then it suppresses the sending of additional ones for that
>host for a couple weeks. My issues arise, when I make an update or addition
>of a rule to the disk.sr file, and SEC gets reloaded - all of these rules
>get their timers and context reset. So...if the disk has not been fixed,
>and it continues to have log messages that SEC acts on, it will send another
>email for an already known issue.
>
>Not sure how to make this more resilient.
Well I add a disk1.sr when I need supplimentary rules. Sec can
dynamically evaluate rules files. I use something like
-conf '/etc/sec/rules/*'
Note the use of ' to prevent the shell expanding the *. This allows
sec to glob it entirely.
Then I watch the dump files to see when I no longer have rules from
that file pending and merge the command files (disk.sr, disk1.sr,
disk2.sr...) and reload. But that's a pain.
You can rewrite them using contexts that won't be wiped (IIRC) when
the file is reloaded, but that leads to a lot of extra rules.
It's been a while since I did this, but if memory serves something
like (note there are errors in here I am sure) :
#1
type=singlewith2thresholds
pattern=p1
thresh=10
window=20
context= !suppress1_context
action=create suppress1_context
thresh2=2
window2=10
action2=delete suppress1_context
# 2
type=single
cont=takenext
pattern=p1
context = !timing_clear_of_suppress1_context && suppress1
action = create timing_clear_of_suppress1_context 10 \
(delete suppress1_context)
# 3
# release the suppress1 threshold
type=threshold
pattern=p1
window=10
thresh=2
context= suppress1_context && timing_clear_of_suppress1_context
action=set timing_clear_of_suppress1_context 10 (delete suppress1); reset
1 is your usual singlewith2thresholds except p1 won't match if the
suppress1_context exists. It is created when the first threshold
fires. So until the second threshold fires, it will exist.
If the rule is reset (by a ruleset load), the context still exists
(IIRC) and thus the singlewith2threholds rule won't fire in th next p1
event. However the single rule (#2) will fire and it creates the
(timed) context timing_clear_of_suppress1_context. This will fire only
once until the second threshold level is met as meeting the second
threshold will delete the timing... context. When the context created
by the single rule expires it will delete the suppress1_context.
Rule #3 counts the number of p1 matching events. If it is greater than
2 in 10 seconds, it extends the life of the context by another 10
seconds and then resets itself to look for two more events in 10
seconds.
Note that: rule #1: window2, #2: action context lifetime, #3: window
and #4 action context lifetime are all the same.
Also #1: thresh2, #3: thresh are the same as well.
This example may have an off by one error in it. I don't remeber if
the #3 thresh needs to be the same as #1 thresh2 or one less than it
(you may lose an instance of a p1 event somewhere in the ruleset as it
triggers the threshold rather than initializing the threshold
rule).
As I said a lot of work for less gain, but it can be made into a
routine that is expanded by something like filepp. You can put this
set of three rules into a file generate the ruleset from a
sec-meta-language if you are so inclined.
However one other issue with preserving correlations is that they are
labeled by their location in the file.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
