Re: application monitoring best practices
From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Wed, 28 Aug 2013 12:45:01 -0500
Message-ID: <CA+fnDAbQR8iG4uUozFHCu4_v_Rwq36_Z3dm5_6+QFqQg3f4tag_at_mail.gmail.com>
First question - is it straightforward to apply a metric extension to only one system when admin groups are being used to apply templates across the entire infrastructure?
And this is what I suppose I'd have to do in order to use metric extensions: 1. create a dozen metric extensions that each run SQL "select count(*) from CustomSchema#.MyTable#" (each CustomSchema# only exists in a single database)
2. apply the extensions to only their respective databases since the SQL would fail anywhere else
3. set a warning and critical threshold for each metric in database, override the admin group templates
4. create custom incident notification rules to catch each custom metric for each database and send emails to CustomEmail#_at_MyDomain#.com
Date: Wed, 28 Aug 2013 12:45:01 -0500
Message-ID: <CA+fnDAbQR8iG4uUozFHCu4_v_Rwq36_Z3dm5_6+QFqQg3f4tag_at_mail.gmail.com>
First question - is it straightforward to apply a metric extension to only one system when admin groups are being used to apply templates across the entire infrastructure?
And this is what I suppose I'd have to do in order to use metric extensions: 1. create a dozen metric extensions that each run SQL "select count(*) from CustomSchema#.MyTable#" (each CustomSchema# only exists in a single database)
2. apply the extensions to only their respective databases since the SQL would fail anywhere else
3. set a warning and critical threshold for each metric in database, override the admin group templates
4. create custom incident notification rules to catch each custom metric for each database and send emails to CustomEmail#_at_MyDomain#.com
Seems like a lot of customization, and difficult to maintain compared to a few lines of PL/SQL which could do the same thing? Even if it does mean duplicating stuff that EM12c does? And is this really what metric extensions "are for"? I always thought that they existed to create new metrics that applied to _many_ systems... for example if you wanted to look at /proc/kernel_file or v$systemview.
-Jeremy
-- http://about.me/jeremy_schneider On Wed, Aug 28, 2013 at 10:09 AM, Job Miller <jobmiller_at_yahoo.com> wrote:Received on Wed Aug 28 2013 - 19:45:01 CEST
> IMO, you should leverage Metric Extensions for this type of monitoring.
> That's what they are for.
>
> Why duplicate the notification and incident tracking framework of EM12c?
>
> Job
>
>
> ------------------------------
> *From:* Kevin Jernigan <kevin.jernigan_at_oracle.com>
> *To:* Mark Bobak <Mark.Bobak_at_proquest.com>
> *Cc:* "jeremy.schneider_at_ardentperf.com" <jeremy.schneider_at_ardentperf.com>;
> Oracle-L <oracle-l_at_freelists.org>
> *Sent:* Tuesday, August 27, 2013 7:51 PM
> *Subject:* Re: application monitoring best practices
>
> Don't get me started - it's part of my job to spread the word about the
> "sleeper" features in the database, such as temporal, CQN, in-db
> archiving, etc...KJ
>
>
-- http://www.freelists.org/webpage/oracle-l