2012/1/17 mindman101 <mindman...@zoho.com>:
> Hi Risto,
>
> Thanks, you were right, I followed your hints and it worked for me.
>
> However, I used copy action instead of report action to catch the follow-up
> events.
>
> The rules look as below:
>
> type=Single
> ptype=RegExp
> pattern=(d{1,4}-d{1,2}-d{1,2})s(d{1,2}:d{1,2}:d{1,2})s(d{1,3}.d{1,3}.d{1,3}.d{1,3})s(linkDown)sifIndexs(d{8}).*ifDescrs+(w+)s(w+)
> varmap= date=1; time=2; ip=3; event=4; ifIndex=5; Descr=6; devname=7
> desc=$+{date} $+{time} $+{ip} Interface down ($+{event}) IP = $+{ip} followed
> by
> action=create linkDown_$+{ip} 3 (copy linkDown_$+{ip} %h; event %s %h alarms
> at $+{devname})
>
> type=Single
> ptype=RegExp
> pattern=(d{1,3}.d{1,3}.d{1,3}.d{1,3})s(w+)svRtrRsvpIfStateChange
> varmap= ip=1; devname=2
> desc=$0
> action=add linkDown_$+{ip} vRtrRsvpIfStateChange
>
> type=Single
> ptype=RegExp
> pattern=(d{1,3}.d{1,3}.d{1,3}.d{1,3})s(w+)svRtrRsvpIfNbrStateDown|
> varmap= ip=1; devname=2
> desc=$0
> action=add linkDown_$+{ip} vRtrRsvpIfNbrStateDown
>
> type=SingleWithSuppress
> ptype=RegExp
> pattern=(d{1,4}-d{1,2}-d{1,2})s(d{1,2}:d{1,2}:d{1,2})s(d{1,3}.d{1,3}.d{1,3}.d{1,3})sInterface
> down.+ats(w+)
> varmap= date=1; time=2; ip=3; devname=4;
> desc=$4
> action=write - $+{date} $+{time} Interface down at $+{devname} and IP =
> $+{ip} supressed for 60 seconds.
> window=60
>
> As you can see, in the first rule I copied the follow-up events to the h
> variable. However,
> I want to mix the content of the h variable with desc content and an extra
> text that follows h variable and feedback
> to Sec at the end of the context.
>
> The event action works fine but I noticed that it feed Sec with multiple
> input streams because the action copy adds
> newline after each event it store in the context. How could I join in a
> single line or input stream the events store
> at h variable? I want a single line so the last rule (SingleWithSuppress) can
> match the input.
>
> Thanks for any suggestion.
hi Gaoke,
if you would like %h to contain the event store of the context as a
single line, you could use a small Perl code snippet for this. The
following two actions take the event store of the CONT context and
write it into %h variable as one line:
copy CONT %h; lcall %h %h -> ( sub { return join(" ", split(/\n/, $_[0])); } );
The lcall action simply splits %h on newline, and then rejoins the
values with a space as a separator.
hope this helps,
risto
>
> Gaoke.
>
> On 12/14/2011 04:19 PM, mindman101 wrote:
>> Hi Risto,
>>
>> Thanks for your answer, you've got the idea.
>>
>> However, I still have a final doubt.
>>
>> The association among root cause and its son events are both IP and device
>> name. So, the Single rule and the Eventgroup rule type work fine from your
>> example but the second one requires that each event arrives at least once.
>>
>> How would you apply a rule like Eventgroup but without needing all events
>> arrive at least once? I mean, the root cause must trigger the context for
>> the son events (the Single rule) but it's desired that the Eventgroup rule
>> match with one, two or more events.
>>
>> For example, I'll call the root cause as P1 and its son events as S1, S2 and
>> S3, then the idea is to match and report the following occurrences:
>>
>> P1 -> S1 or
>> P1 -> S3& S2 or
>> P1 -> S2& S3& S1 or
>> any other combination
>>
>> Cheers,
>>
>> Gaoke
>>
>
> I would address this problem with the following rule logic:
>
> 1) have a rule which matches P1 event with Single rule and creates a
> context for the host name and interface name (for example,
> PROBLEM_host12_eth3).
> Set the context lifetime to N seconds and action-on-expire to something
> that reports the context event store. N is the window for capturing P1
> and optional S1, S2 and S3 that might follow.
> Finally, add P1 to the context as the first event.
>
> 2) have three Single rules which match S1, S2 and S3 events if the
> context PROBLEM_ exists for a given host name and interface name. Each
> time there is a match, the event is added to the context.
>
> Since in the first rule you have configured reporting the context, P1
> and optional follow-up events S* will get reported after N seconds.
>
> In the SEC FAQ, there is an example which follows this thinking quite
> closely: http://simple-evcorr.sourceforge.net/FAQ.html#17
> Although it is written for events of one type only, I think it is
> straightforward to extend it for several event types, given the examples
> you already have from previous posts.
>
> HTH,
> risto
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
