By George, I think I've got it :-)
John, thanks so much for the help (and patience!)
For future searches, here's what I ended up with:
# Match IP SLA events
# Jun 3 11:39:08 10.48.36.39 334031: 334645: Jun 3 11:39:08.208 BST:
%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3550
# Jun 3 11:39:33 10.48.36.39 334037: 334651: Jun 3 11:39:33.232 BST:
%RTT-4-OPER_TIMEOUT: condition cleared, entry number = 3550
#
# The two rules below should watch for a "condition occurred" event and,
# if no matching "condition cleared" event comes in for the same IP with the
same
# probe number BEFORE a new "condition occurred" event comes in for that
device/probe #
# then we need to trigger an alert
# (note that probe # is the "entry number =" in the example above)
type = single
desc = email when an alert is seen while one is asserted
continue = takenext
context = alert_$1_$2
ptype = regexp
rem = $1 is ip address, $2 is entry number
pattern = ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*occurred, entry
number = (\d+)
action = pipe '$0' /usr/bin/mail -s "IP SLA - Condition occurred without
clear" some...@somewhere.com; delete alert_$1_$2; reset
+1 match the alert for host $1 and event $2
type = pair
desc = match the alert for host $1 and event $2
ptype = regexp
rem = same pattern as in single rule
pattern = ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*occurred, entry
number = (\d+)
action = create alert_$1_$2
desc2 = match the clear for host $1 and event $2
ptype2 = regexp
pattern2 = $1.*cleared, entry number = $2
rem = %1 and %2 are used to reference $1 and $2 from the first pattern
rem = since this is run after pattern2 is matched, $1 and $2 are
rem = reassigned by the pattern2 match
action2 = delete alert_%1_%2;
time = 0
On Fri, Jun 4, 2010 at 10:34 PM, John P. Rouillard <rou...@cs.umb.edu>wrote:
>
> In message <aanlktik_7odx7o3da6paktxgcclvxdocgoxsuctz3...@mail.gmail.com>,
> Clayton Dukes writes:
>
> ># Match IP SLA events
> ># Jun 3 11:39:08 10.48.36.39 334031: 334645: Jun 3 11:39:08.208 BST:
> >%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3550
> ># Jun 3 11:39:33 10.48.36.39 334037: 334651: Jun 3 11:39:33.232 BST:
> >%RTT-4-OPER_TIMEOUT: condition cleared, entry number = 3550
> >#
> ># The two rules below should watch for a "condition occurred" event and,
> ># if no matching "condition cleared" event comes in for the same IP with
> the
> >same
> ># probe number BEFORE a new "condition occurred" event comes in for that
> >device/probe #
> ># then we need to trigger an alert
> ># (note that probe # is the "entry number =" in the example above)
> >type = single
> >desc = email when an alert is seen while one is asserted
> >continue = takenext
> >context = alert_$1_$2
> >ptype = regexp
> >rem = $1 is ip address, $2 is entry number
> >pattern = ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*occurred,
> entry number = (\d+)
> >action = pipe '$0' /usr/bin/mail -s "IP SLA - Condition occurred without
> >clear" cdu...@cisco.com; delete alert_$1_$2; reset +1 match
> > the alert for host $1 and event $2
> >
> >type = pair
> >desc = match the alert for host $1 and event $2
> >ptype = regexp
> >rem = same pattern as in single rule
> >pattern = ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*cleared, entry
> >number = (\d+)
> >action = create alert_$1_$2
> >desc2 = match the clear for host $1 and event $2
> >ptype2 = regexp
> >pattern2 = $1.*occurred, entry number = ($2)
> >rem = %1 and %2 are used to reference $1 and $2 from the first pattern
> >rem = since this is run after pattern2 is matched, $1 and $2 are
> >rem = reassigned by the pattern2 match
> >action2 = delete alert_%1_%2; pipe '$0' /usr/bin/mail -s "IP SLA -
> something
> >happened" cdu...@cisco.com
> >time = 0
>
> Ah you have swapped the values of pattern and pattern2 in your pair
> rule. The pattern in the pair rule should be the first element in the
> pair you are trying to match. Namely:
>
> pattern = ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*occurred,
> entry number = (\d+)
>
> pattern2 should be the clear entry:
>
> pattern2= $1.*cleared, entry number = $2
>
> >So, if I run this using /var/log/syslog as input:
> > sec -conf /etc/sec.conf -debug 10 -input=/var/log/syslog
> >
> >I (eventually) get this:
> >
> >Creating context 'alert_10.48.36.34_3820'
> >Creating context 'alert_10.48.36.40_3712'
> >Creating context 'alert_10.48.36.40_3747'
> >...snip
> >Creating context 'alert_10.48.36.34_3652'
> >Feeding event 'Jun 4 19:23:21 10.48.36.40 188461: 188997: *Jun 4
> >19:23:17.318 BST: %RTT-4-OPER_TIMEOUT: condition occurred, entry number =
> >3712' to shell command '/usr/bin/mail -s "IP SLA - Condition occurred
> >without clear" cdu...@cisco.com'
> >Child 730 created for command '/usr/bin/mail -s "IP SLA - Condition
> occurred
> >without clear" cdu...@cisco.com'
> >Deleting context 'alert_10.48.36.40_3712'
> >Context 'alert_10.48.36.40_3712' deleted
> >Cancelling the correlation operation with key '/etc/sec.conf | 1 | match
> the
> >alert for host 10.48.36.40 and event 3712'
> >Creating context 'alert_10.48.36.41_3208'
>
> Yup that makes sense given the rules you have.
>
> The first event (condition occurred) does nothing.
>
> The second event (condition cleared) starts the pair rule and creates
> the context.
>
> Then you get the the third event (condition occurred) which is matched
> by the single rule (since the context was set by prior condition
> cleared event) and the email is sent. The pair correlation is killed
> and the event is ignored by the pair rule since the first element in
> the pair is looking for a condition clear and not a condition occurred.
>
> >But, when I look at my syslog.log, I see the matching events (in order),
> so
> >I don't know why it triggered an alert:
> >
> >Jun 4 19:07:51 10.48.36.40 188373: 188909: *Jun 4 19:07:47.297 BST:
> >%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3712
> >Jun 4 19:08:16 10.48.36.40 188377: 188913: *Jun 4 19:08:12.285 BST:
> >%RTT-4-OPER_TIMEOUT: condition cleared, entry number = 3712
> >Jun 4 19:23:21 10.48.36.40 188461: 188997: *Jun 4 19:23:17.318 BST:
> >%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3712
> >Jun 4 19:23:46 10.48.36.40 188464: 189000: *Jun 4 19:23:42.303 BST:
> >%RTT-4-OPER_TIMEOUT: condition cleared, entry number = 3712
> >
> >So here we have 1 "occurred" followed by 1 "cleared" (then repeated one
> more
> >time)
>
> But your pair rule is looking for a "condition cleared" followed by a
> "condition occurred" and the single rule ends up alerting if a
> "condition occurred" happens after a "condition cleared". Which is
> what happens when event 3 is seen.
>
> >If the incoming messages would have looked like this:
> >Jun 4 19:07:51 10.48.36.40 188373: 188909: *Jun 4 19:07:47.297 BST:
> >%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3712
> >Jun 4 19:23:21 10.48.36.40 188461: 188997: *Jun 4 19:23:17.318 BST:
> >%RTT-4-OPER_TIMEOUT: condition occurred, entry number = 3712
> >Jun 4 19:23:46 10.48.36.40 188464: 189000: *Jun 4 19:23:42.303 BST:
> >%RTT-4-OPER_TIMEOUT: condition cleared, entry number = 3712
> >
> >That's when I need to get an email trigger because I have an "occurred"
> >before a "cleared" event came in.
> >I don't know if my pattern tests in the rule are correct - do I look for
> >"occurred", then "cleared"?
>
> Correct. The pairing is in time, so the first element of the pair is
> the one that occurs first in time i.e. the "occurred".
>
> >Do I look for 2 "occurred"'s?
>
> Nope, what you are looking for is a pair occurred/clear. If in the time
> between the occurred and the clear another occurred comes in the single
> rule triggers. That's what is looking for the second occurred within
> the window formed by an occurred and it's matching clear.
>
> Does that make sense?
>
> >Sorry for my noobness, I tell all of my customers they should be using
> SEC,
> >but I don't get many opportunities to use it myself since I'm usually
> >"advising" :-)
>
> I know what you mean. Thanks for encouraging the use of SEC.
>
> >Hopefully I haven't confused you more :-)
>
> Nope. this example makes perfect sense. Hopefully my response does as
> well.
>
> Also just to note that the mailing lists archives are publically
> accessible. I usually remove email addresses (or at least delete the
> @dom.ain part) so that it can't be picked up by spammers.
>
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
--
______________________________________________________________
Clayton Dukes
______________________________________________________________
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
