2011/4/15 John Grasett <john.gras...@atech.com>:
> Yes, that sounds perfect. I could also then do this to not repeat on the
> same event in the same log.
>
> type=single
> ptype=perlfunc
> pattern=sub { if ($_[0] =~ /.*(SRVE0255E).*/) { \
> return ($1, $_[1]); } else { return 0; } }
> context=!IGNORE_SRVE0255E_FOR_FILE_$2
> desc=$0
> action=logonly Error reported by Application: %app on Layer: %layer:
> $1 caught in: $2; create IGNORE_SRVE0255E_FOR_FILE_$2
>
>
> One other thing I am triyng to do with no luck - change $2 to be only part
> of the log path/filename:
>
> type=single
> ptype=perlfunc
> pattern=sub { if ($_[0] =~ /.*(SRVE0255E).*/) { \
> return ($1, $_[1], $_[2] =~ m/.*\/(.*)\.SystemOut\.log$/); } else { return
> 0; } }
> desc=$0
> action=logonly Error reported by Application: %app on Layer: %layer: $1
> caught in: $2
>
> or I try
>
> return ($1, $_[1] =~ m/.*\/(.*)\.SystemOut\.log$/); } else { return 0; } }
>
> But then I get bad output!
John,
PerlFunc pattern function accepts two input parameters ($_[0] and
$_[1]), thus $_[2] is undefined for this pattern (PerlFunc2,
PerlFunc3, PerlFunc4 etc. take 2,4,6,... parameters).
I would not recommend using $_[1] =~ m/.*\/(.*)\.SystemOut\.log$/
inside a return list from the function, since this sets $1 to the
match value from m/.*\/(.*)\.SystemOut\.log$/, overwriting a previous
value from /.*(SRVE0255E).*/. You can tackle this issue by saving $1
first into a separate variable, and then evaluating
m/.*\/(.*)\.SystemOut\.log$ against the input file name.
hope this helps,
risto
>
>
>
>
> -----Risto Vaarandi <risto.vaara...@gmail.com> wrote: -----
>
> To: John Grasett <john.gras...@atech.com>
> From: Risto Vaarandi <risto.vaara...@gmail.com>
> Date: 04/15/2011 12:43PM
> Cc: simple-evcorr-users@lists.sourceforge.net
> Subject: Re: [Simple-evcorr-users] Suggestions for handling multiple
> streams/events - disabling alerting based on source, etc.
>
> hi John,
> I would recommend to use contexts, once you have seen a match from
> particular rules that should disable matches for several other rules.
> The contexts are visible across all rules and it is easy to check
> their presence or absence with Boolean expressions.
> For example, for disabling input coming from certain log files, you
> could employ the following scheme:
>
> type=single
> ptype=perlfunc
> pattern=sub { if ($_[0] =~ /.*(SRVE0255E).*/) { \
> return ($1, $_[1]); } else { return 0; } }
> desc=$0
> action=logonly Error reported by Application: %app on Layer: %layer:
> $1 caught in: $2; create IGNORE_EVENTS_FOR_FILE_$2
>
> type=single
> ptype=perlfunc
> pattern=sub { if ($_[0] =~ /.*(SRVA0255A).*/) { \
> return ($1, $_[1]); } else { return 0; } }
> context=!IGNORE_EVENTS_FOR_FILE_$2
> desc=$0
> action=logonly Error2 reported by Application: %app on Layer: %layer:
> $1 caught in: $2
>
> The first rule creates a context if SRVE0255E event has been seen for
> an input file, and if then the SRVA0255A event will come in from the
> same log file, no alert would be produced.
>
> A side note -- since the users like to have an input source file name
> to be available through a match variable, and the named match
> variables added into the new 2.6 version allow for easily adding new
> reserved variables, it is likely that the next minor version of SEC
> will include support for input file name match variable. In that case,
> you wouldn't be required to use PerlFunc anymore only for getting
> input source name.
>
> kind regards,
> risto
>
>
> 2011/4/14 John Grasett <john.gras...@atech.com>:
>> I am just getting started here, but I know we will be able to get what we
>> want, I just need a little push in the right direction for implementing
>> this. So far I have this simple conf:
>>
>> # Set variables on SEC startup or soft restarts. These variables can be
>> used
>> # in actions and contexts. They are not usable in patterns.
>> type = single
>> desc = set variables and things on startup or restart of sec (core)
>> ptype = regexp
>> pattern = SEC_(STARTUP|RESTART|SOFTRESTART)
>> context = [ SEC_INTERNAL_EVENT ]
>> action=assign %app WEC; assign %layer PERF
>>
>> # test rule to match on error generated by webshere for a bad or missing
>> virtual host or webgroup
>> # we use a perlfunc as we need to get the name of the input stream (in
>> this
>> case our logfile) - this way we can run one instance against
>> # all the servers for an application/layer
>> type=single
>> ptype=perlfunc
>> pattern=sub { if ($_[0] =~ /.*(SRVE0255E).*/) { \
>> return ($1, $_[1]); } else { return 0; } }
>> desc=$0
>> action=logonly Error reported by Application: %app on Layer: %layer: $1
>> caught in: $2
>>
>> which does what it should, logs on catching the SRVE0255E code with the
>> variables and the name of the logfile it was caught in:
>>
>> Thu Apr 14 12:37:28 2011: Reading configuration from
>> /opt/monty/sec/conf/WEC_PERF.conf
>> Thu Apr 14 12:37:28 2011: 2 rules loaded from
>> /opt/monty/sec/conf/WEC_PERF.conf
>> Thu Apr 14 12:37:28 2011: Creating SEC internal context
>> 'SEC_INTERNAL_EVENT'
>> Thu Apr 14 12:37:28 2011: Creating SEC internal event 'SEC_RESTART'
>> Thu Apr 14 12:37:28 2011: Assigning 'WEC' to variable '%app'
>> Thu Apr 14 12:37:28 2011: Assigning 'PERF' to variable '%layer'
>> Thu Apr 14 12:37:28 2011: Deleting SEC internal context
>> 'SEC_INTERNAL_EVENT'
>> Thu Apr 14 12:37:44 2011: Error reported by Application: WEC on Layer:
>> PERF:
>> SRVE0255E caught in: /logs/PERF/WAS/WEC/current/PQWCSP2.SystemOut.log
>>
>> now, what I am looking for direction for is this:
>>
>> After matching a rule...
>>
>> We may want to suppress alerting/logging of this particular event from
>> this
>> particular source for some time.
>> We may want to suppress alerting/logging of any/all events from this
>> particular source for some time.
>>
>> I imagine we have to setup contexts, but can I use the name of the logfile
>> (or better, just the servername - see below) within a context somehow to
>> suppress actions based on the event and the source (or just the source)?
>>
>> I would actually like to extract the value which is the servername from
>> the
>> source (eg get just PQWCSP2 out of
>> /logs/PERF/WAS/WEC/current/PQWCSP2.SystemOut.log) - and I think I can do
>> this with an eval, or since these values are known (in fact passed to the
>> wrapper script that starts SEC), I can just hard code them.
>>
>> SEC looks like a fantastic solution to a lot of tasks, I am surprised I
>> have
>> not run across it before, but am pleased to have done so, and I hope the
>> folks I am solutioning this for agree once I can show them a full fledged
>> implementation.
>>
>> Cheers!
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about
>> boosting
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>> _______________________________________________
>> Simple-evcorr-users mailing list
>> Simple-evcorr-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>
>>
>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
