2012/8/14 John P. Rouillard <rou...@cs.umb.edu>:
> Hi all:
>
> I know this should be doable, and I know my current thinking is
> barking up the wrong tree, but my brain is locked into doing something
> and it's not quite working.
>
> Here's what happened. In order to get the output from postgres into
> the proper form to be used by an performance analysis application, I
> have to change the prefix for every log message.
>
> Needless to say that will require some changes to the exiting parsing
> rules in SEC.
>
> My inital thought was that I could set up a single rule to parse the
> new prefix and then use the results of that parsing in additional
> rules via $+{named_variables}. This would let me do 3 things:
>
> 1) limit the number of places I need to write the prefix
> regexp to extract fields (it may change again in the future)
> 2) only apply the regexp for the prefix extraction once
> rather than dozens of times for each rule in the ruleset
> 3) as a result of 2 eliminate a performance bottleneck caused
> by applying the somewhat complex prefix regexp for every rule
>
> My initial setup was:
>
> type = single
> ptype = regexp
> pattern = .....
> varmap = pg_prefix; date=1; host=2; db=3; user=4; level=5; event=6; eorder=7
> action = none
> continue=takenext
>
> type = single
> pattern = LOG: duration: (\d+\.\d+)
> context = !pg_log_event_$+{host}_$+{event} && =( $1 > 2 )
> rem = here is an action specific to the duration log lines.
> action add pg_log_event_$+{host}_$+{event} $0
>
> and so forth. For a varmap without a pg_prefix; argument, the $+{}
> variables aren't defined except in the scope of the rule with the
> varmap. This makes sense as their underlying variable $1...$N only
> have the scope of a single rule.
>
> However, it turns out you can't access the $+{} variables in the
> second rule even with the pg_prefix; argument unless the second
> rule is of the form:
>
> type = single
> ptype = cached
> pattern = pg_prefix
> ....
Just to clarify the question -- are you trying to use $+{} match
variables in the second rule after the first rule has matched, but use
another regular expression for the pattern in the second rule? If so,
then unfortunately this way of matching does not work, since $+{} and
$N match variables have identical scopes. They can both be referred
only within the current rule, and following matches always reset them
(unless they are cached and then retrieved from the cache with a
'Cached' pattern).
One way to address the problem would be to set up appropriate
context(s) and/or action list variable(s) for passing matching results
from one rule to another.
There is also another way (a feature which was added to the 2.6.2
version) -- you can rewrite your input events on the fly with the
'rewrite' action. This action was added specifically for handling
issues related to log message format changes. Maybe you can rely on
this action to tackle the problem at hand?
with kind regards,
risto
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
