Re: application monitoring best practices
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: Job Miller <jobmiller@xxxxxxxxx>
- Date: Wed, 28 Aug 2013 12:45:01 -0500
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#@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@xxxxxxxxx> wrote:
> 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@xxxxxxxxxx>
> *To:* Mark Bobak <Mark.Bobak@xxxxxxxxxxxx>
> *Cc:* "jeremy.schneider@xxxxxxxxxxxxxx" <jeremy.schneider@xxxxxxxxxxxxxx>;
> Oracle-L <oracle-l@xxxxxxxxxxxxx>
> *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
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
