On Mon, 14 Jul 2014, John P. Rouillard wrote:

> Hello:
>
> In message
> <cadjfwj24kjccra3rnvwn+peg03vc+hihyd1z9_d30o4pfsx...@mail.gmail.com> ,
> Yuheng Du writes:
>
>> I made two rules, I extract some information and assign it to an variable
>> in the first rule. How can I use the variable in the second rule? Here are
>> my two rules:
>>
>> #Rule 1: extract the deploymentId from log and assign it to variable %
>> deploymentId.
>> type=Single
>> ptype=RegExp
>> desc=$0
>> pattern=\"deploymentId\"\s+=>\s+(\S+)deployment#(\S+)\",
>> action=assign %deploymentId $2;\
>>       create DEPLOYMENTID_CONTEXT;
>>
>> #Rule 2: try to use %deploymentId value in the pattern expression.
>> type=Single
>> ptype=RegExp
>> pattern=status\s+of\s+(%deploymentId)\s+to\s+dead
>> desc=CHECK_DEAD
>> action=write - %deploymentId dead notified.
>>
>> SEC does not recognize the variable's value in my Rule 2's pattern. Can
>> anyone help me with it?
>
> I may be wrong, but I don't think action variables
> (e.g. %deploymentId) are replaced in patterns. So rule 2 needs the
> event to include the exact string '%deploymentId' and not its value in
> order to match (e.g. "status of %deploymentId to dead").

right, variables defined in one rule only last for that rule

> There are at least two ways to make this work:
>
>  1) use a context to tie the two single rules together
>  2) use a pair rule

3. you can resort to perl variables, which last forever (which can be a problem 
as well)

David Lang

> To use a context change the rules to:
>
> #Rule 1: extract the deploymentId from log and create a context
> # indicating it was seen
> type=Single
> ptype=RegExp
> desc=$0
> pattern=\"deploymentId\"\s+=>\s+(\S+)deployment#(\S+)\",
> rem = note the context created is unique for each deploymentId
> action=assign %deploymentId $2; \
>       create deploymentId_$2_seen;
>
> #Rule 2: extract a deploymentId in the pattern and see if it
> # has a context created for it.
> type=Single
> ptype=RegExp
> pattern=status\s+of\s+(\S+)\s+to\s+dead
> desc=CHECK_DEAD
> rem = we only execute this rule if there is a pre-existing
> rem =  context that matches the deploymentId in $1
> context = deploymentId_$1_seen
> rem = since %deploymentId is an action variable, it can be used
> rem = in an action statement
> action=write - %deploymentId dead notified. ;\
>       delete deploymentId_$1_seen
> # or:
> #    action=write - $1 dead notified. ; \
> #        delete deploymentId_%{deploymentId}_seen
> # would also work. (I think %{var} is needed to expand the variable
> # since _ is an allowed character in variable names
>
> rule 2 only fires if rule 1 fired before it and created the matching
> context.
>
> Note this way you can have the following sequence of events:
>
> "deploymentId" => somedeployment#2345",
> "deploymentId" => somedeployment#345",
> status of 2345 to dead
> status of 345 to dead
>
> and get two written messages:
>
>   2345 dead notified.
>   345 dead notified.
>
> With your original solution using %deploymentId, the same sequence
> of events would only produce:
>
>   345 dead notified.
>
> since %deploymentId would not have the value 2345 when the
>
>  status of 2345 to dead
>
> event was seen.
>
> The other way to do it is as a pair rule:
>
> type = pair
> rem = note including $2 in the desc field.
> rem = this is required to start different correlation operations
> rem = for each deploymentId as they come though.
> desc = see first deployment id $2
> ptype=RegExp
> pattern=\"deploymentId\"\s+=>\s+(\S+)deployment#(\S+)\",
> rem = the pattern above assigns the deploymentId to $2
> rem = which is used in pattern2 to match exactly the corresponding
> rem  = event that must occur after pattern is matched.
> action = none
> rem = we do nothing when the fisr event is matched
> desc2 = CHECK DEAD
> ptype2 = regexp
> pattern=status\s+of\s+($2)\s+to\s+dead
> rem = in pattern2, we use $2 which is the value set by "pattern"
> rem = however since pattern2 also sets the match variables
> rem = ($0, $1 and wipes $2), we can't reference the value using $2 in
> rem = action statements, we used %2 rather than $2.
> action2 = write - %2 dead notified.
> # also
> #  action2 = write - $1 dead notified.
> # would work since $1 in this action statement is equal to $2 from the
> # first pattern.
>
> Given the sequence of events I gave above, the pair rule will
> also produce two messages not one.
>
> I think there is a third way by using action expressions in the
> context, but I don't think that has any advantage over these two
> methods.
>
> (Note the rules above are from my memory of the SEC man page, so
> they may need to be tweaked a little to et them to work.)
>
> Hopefully this will solve your problem.
>
> --
>                               -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users

Reply via email to