It was for minimizing the number of rules I'd have to create, and not for reporting.
What we're doing is creating a self-service GUI that allows anyone to select a number of rules to create their own event-stream logic. For "PairWithWindow" we currently have a list drop down and you select the time... which means that you must have one rule for each time specified. If "Window" was a variable, then only one rule of a given type would be necessary. It's not a big deal, as we only have 6 or so times allowed, but if there were a way to set Window as a variable, then I'd make the window completely user-selectable. -----Original Message----- From: Risto Vaarandi [mailto:risto.vaara...@seb.ee] Sent: Friday, March 08, 2013 7:53 AM To: simple-evcorr-users@lists.sourceforge.net Subject: Re: [Simple-evcorr-users] PairWithWindow Help Needed. On 03/06/2013 05:37 PM, Boyles, Gary P wrote: > Risto, > Thanks for taking the time to analyze my rule, and put together > your concise explanation > > I guess I misunderstood how "desc2" could be used. > > I've changed context to include a node-name check, and that solved the > problem. > > One final question -- is there any way to make "Window" for "Pair" operations > a variable or accessed via a perl routine? hi, unfortunately, that's not possible. Do you want to obtain the size of the window for reporting purposes, or do you intend to modify the window size? kind regards, risto > > Thanks a lot for your help. > > Gary Boyles > > > -----Original Message----- > From: Risto Vaarandi [mailto:risto.vaara...@gmail.com] > Sent: Tuesday, March 05, 2013 4:56 AM > To: Boyles, Gary P > Cc: simple-evcorr-users@lists.sourceforge.net > Subject: Re: [Simple-evcorr-users] PairWithWindow Help Needed. > > hi Gary, > you have run into a subtle issue that is related to pattern2 > processing when the same Pair* rule has started several operations. > The desc field of your rule is working properly, since you are seeing > different PairWithWindow operations in memory for different nodes. > However, when you have several operations running simultaneously and > an event comes in which reaches the PairWithWindow rule, the event > matching is done in the following way: > 1) if pattern field matches, the event either starts a new operation > or is consumed by some existing operation. If a new operation is > started, match variables are substituted in pattern2 field, and the > resulting pattern is compiled and stored into the operation > 2) if pattern field does not match, *all* operations started by the > rule are checked, and the pattern2 stored in each operation is matched > against an incoming event. For each match, the action2 is executed. > > This behavior is also documented in the SEC man page under the Pair > and PairWithWindow rules. > > The reason you are seeing multiple actions executed seems to be the > following -- since neither pattern2 nor context2 does not include any > check for the node name, any node can pass these checks, and therefore > each operation for the same monitor and severity executes action2, > even if node names are different. > > To fix this, you simply need to include node name constant (held by > $2) either inside pattern2 or context2. > > kind regards, > risto > > 2013/3/4 Boyles, Gary P<gary.p.boy...@intel.com>: >> >> >> Hi, >> >> I have a problem with the following "PairWithWindow" rule. It's either my >> logic, a bug, or the way I understand the rule should work. >> >> >> >> Here is the rule in question: >> >> >> >> type=PairWithWindow >> >> window=60 >> >> continue=GoTo END_CORRELATE_PAIR_WITH_WINDOW >> >> ptype=RegExp >> >> pattern=(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(.*)\s+::\s+(\S+.*) >> >> context=($4 $5) -> ( sub { if ( defined $correlate1{"$_[0]::$_[1]::60"}) { >> return 1;} }) >> >> desc=Correlate1_PWW_60_A::$2::$4::$5 >> >> action=write /sec/log/sec.main.log %u %s; write /sec/log/sec.main.log %u $1 >> :: $2 :: $3 :: $4 :: $5 :: $6 :: $7 >> >> continue2=GoTo END_CORRELATE_PAIR_WITH_WINDOW >> >> ptype2=RegExp >> >> pattern2=(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(\S+)\s+::\s+(.*)\s+::\s+(\S+.*) >> >> context2=(%4 %5 $4 $5) -> ( sub { if ( $correlate1{"$_[0]::$_[1]::60"} =~ >> /$_[2]::$_[3]/i) { return 1;} }) >> >> desc2=Correlate1_PWW_60_B::%2::$2::%4::$4::%5::$5 >> >> action2=write /sec/log/sec.main.log %u %s; write /sec/log/sec.main.log %u $1 >> :: $2 :: $3 :: $4 :: $5 :: $6 :: $7 >> >> >> >> The hoped-for logic is as follows: >> >> >> >> I send in events in the following format: >> >> >> >> # Timestamp NodeName Class Monitor Severity Route Message >> >> # --------- -------- ----- -------- -------- ------ ------- >> >> # $1 :: $2 :: $3 :: $4 :: $5 :: $6 :: $7 >> >> >> >> >> >> If an event comes in from nodeA and it matches monitorA::CRITICAL::60 in >> the "correlate1" table, then the PairWithWindow starts. >> >> Since "desc=" includes node::monitor::severity I assumed that events with >> different nodes would start different "PairWithWindow" instances. >> >> >> >> If I send in another event from nodeB, and it matches monitorA::CRITICAL::60 >> in the "correlate1" table, then another PairWithWindow starts (as expected). >> >> >> >> If I do another event from nodeC - yet another PairWithWindow instance >> starts. >> >> >> >> If after 60 seconds no matching event for any PairWithWindow occurs... then >> "action" occurs for events nodeA, nodeB, and nodeC - as expected (see log >> below) >> >> >> >> However, if I initiate all PairWithWindow events above, and initiate ONE >> "pattern2" option below... then ALL "action2" actions >> >> get executed. Not just the instance that pertains to a single node. >> >> >> >> Now, I can fix this by adding the nodes to the "correlate1" hash-table key, >> but I didn't think this is the way to handle this. >> >> >> >> I had thought... that since I had node-name described in the "desc=" >> definition, that the events would be separated by node::monitor::severity, >> >> and not just the monitor::severity. >> >> >> >> Is this not the case. If not... how is "desc=" used? >> >> >> >> Thanks for your help. >> >> >> >> Regards, >> >> >> >> Gary >> >> >> >> >> >> (Log-File Output Below) >> >> >> >> (this is what happens if I wait for 60-second timer to expire) >> >> >> >> 1362155066 Correlate1_PWW_60_A::gpbuxA::gpbMonitor4::CRITICAL >> >> 1362155066 00 :: gpbuxA :: class :: gpbMonitor4 :: CRITICAL :: i=:n=:a=: :: >> Test Message >> >> 1362155071 Correlate1_PWW_60_A::gpbuxB::gpbMonitor4::CRITICAL >> >> 1362155071 00 :: gpbuxB :: class :: gpbMonitor4 :: CRITICAL :: i=:n=:a=: :: >> Test Message >> >> 1362155077 Correlate1_PWW_60_A::gpbuxC::gpbMonitor4::CRITICAL >> >> >> >> >> >> (this is what happens when I send in ONE event that matches pattern2 for >> either A,B, or C... all 3 seem to unwind together) >> >> >> >> 1362155077 00 :: gpbuxC :: class :: gpbMonitor4 :: CRITICAL :: i=:n=:a=: :: >> Test Message >> >> 1362155281 >> Correlate1_PWW_60_B::gpbuxB::gpbuxB::gpbMonitor4::gpbMonitor4::CRITICAL::OK >> >> 1362155281 00 :: gpbuxB :: class :: gpbMonitor4 :: OK :: i=:n=:a=: :: Test >> Message >> >> 1362155281 >> Correlate1_PWW_60_B::gpbuxC::gpbuxB::gpbMonitor4::gpbMonitor4::CRITICAL::OK >> >> 1362155281 00 :: gpbuxB :: class :: gpbMonitor4 :: OK :: i=:n=:a=: :: Test >> Message >> >> 1362155281 >> Correlate1_PWW_60_B::gpbuxA::gpbuxB::gpbMonitor4::gpbMonitor4::CRITICAL::OK >> >> 1362155281 00 :: gpbuxB :: class :: gpbMonitor4 :: OK :: i=:n=:a=: :: Test >> Message >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Simple-evcorr-users mailing list >> Simple-evcorr-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
