Risto, Yes, I'm specifying integers through a web interface. At this point though, it is through a list of integers rather than free-form integers.
I'm trying to minimize the number of rules written, by utilizing hash-tables to decide on whether a particular node or group will use a particular rule (via context). The problem with just writing out rules is that you might have a rule for a window of 1 second, one for 2 seconds, one for 30 seconds, etc. And since there are a lot of users that might use this interface, I'd rather have one rule that looks at values in a hash for context to determine whether to use a particular rule or not. I have implemented a form of suppression (aka duplicate-detection) with what you describe below (i.e. two "Single" rules with context set via hash-variable). This way... I only need two rules to implement "SingleWithSuppress" for any time-window. I will look at doing the same thing and replicating PairWithWindow. Thanks for your help. Gary -----Original Message----- From: Risto Vaarandi [mailto:[email protected]] Sent: Wednesday, March 13, 2013 7:17 AM To: Boyles, Gary P Cc: [email protected] Subject: Re: [Simple-evcorr-users] PairWithWindow Help Needed. On 03/08/2013 07:18 PM, Boyles, Gary P wrote: > 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. ...just of curiosity, are the users actually specifying integer constants through a web interface? If so, then actually you can do a simple sanity check for the submitted value, and write it into the SEC rule file as a constant. Of course, if the users want to use actual SEC variables for the window (such as $1), things become more complex. But in that case, it might be possible to implement a PairWithWindow rule through two Single rules, with a context of variable lifetime acting as a connector between two rules. Since contexts accept variables for their lifetime, that might be a solution for the problem. kind regards, risto > > > -----Original Message----- > From: Risto Vaarandi [mailto:[email protected]] > Sent: Friday, March 08, 2013 7:53 AM > To: [email protected] > 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:[email protected]] >> Sent: Tuesday, March 05, 2013 4:56 AM >> To: Boyles, Gary P >> Cc: [email protected] >> 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<[email protected]>: >>> >>> >>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > > ------------------------------------------------------------------------------ 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_mar _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
