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.
------------------------------------------------------------------------------
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
