type=single
ptype=perlfunc
pattern=sub { if ($_[0] =~ /.*(SRVE0255E).*/) { \
return ($1, $_[1]); } else { return 0; } }
context=!IGNORE_SRVE0255E_FOR_FILE_$2
desc=$0
action="" 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="" 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!
-----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="" 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="" 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="" %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="" 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
