Monitoring Oracle targets (databases, host systems, listeners, etc.) is another key responsibility of DBAs. Since Oracle 10g, we’ve been able to take advantage of using metric performance measurements and proactive server generated alerts to help us monitor and manage these targets.
Oracle provides hundreds of out-of-the box metrics and alerts across all of the various targets that are monitored using Oracle 12 Cloud Control; however, even with all of the built-in solutions, there is still a requirement to be able to create our own custom metrics and alerts that are more specific to our environments.
Oracle first introduced User-Defined Metrics to address this need, and in Oracle Enterprise Manager 12c Cloud Control they have been re-defined as Metric Extensions. Metric Extensions allow DBAs to define the metric, collection information and set up alerts based on those custom metrics.
Metric extensions go beyond the previous user-defined metrics by greatly extending the number and types of targets that can be used as the target of customized metrics. Targets now include hosts, databases, fusion applications, IBM Websphere, Oracle Exadata, Seibel, and Oracle Business Intelligence components.
Additionally, user-defined metrics were pretty well limited to OS scripts on host targets and SQL queries for database targets. OS scripts had to be written to ensure only a single value was returned for testing against the thresholds for alerts. SQL query based metrics could handle multiple values, but we were still limited in setting up collection information. There was no ability to create custom metrics and alerts on other target types. With metric extensions many of these limitations of user-defined metrics are eliminated.
The main functionality behind Metric Extensions are Oracle Integration Adapters. The adapters are used to gather information from the targets, and different adapters are available for different target types.
Privileges for Metric Extensions
In order to create, edit and manage extensions, like most things in Cloud Control, there are a prerequisite set of privileges. The main privilege is Create Metric Extension – and there are several levels of access.
- Create metric extension – create, view, deploy, edit and delete metric extensions
- edit metric extension – modify existing metric extensions but not delete
- full metric extension – allows deletion of existing metric extensions
- manage metrics – deploy and un-deploy on targets
Granting the appropriate privileges can be done through the security menu. Go to Setup>Security>Administrators. Edit the appropriate administrator account and go to the Resource Privileges tab and select Manage Privilege Grants. From here the Create Metric Extension privilege can be granted to the administrator account.
Working with Metric Extensions
There are basically three steps for working with metric extensions – develop the extension, test it and deploy and publish the extensions.
In developing the metric extension, decide what needs to be measured, which target type it will apply to, how the underlying data will be collected (which adapter to use), what credentials will be used (and do you need higher level credentials to be able to gather the data). Also, make sure you take a look at the out-of-the-box extensions first, don’t “re-create the wheel”.
Once you know what you need, Cloud Control has a wizard interface to help you get the metric created and operational, including the ability to test your metric against a target through the wizard without necessarily having to deploy it to do the testing.
When metric extensions are first created, they are “private” which means only the administrator creating the metric will be able to see and test it. Once it has been properly tested it can be deployed and then made available to other administrators in Cloud Control.
The Metric Extension wizard is accessed via Enterprise>Monitoring>Metric Extensions menu. Choose Create New to launch the wizard.
The basic steps of the wizard are:
a) assign a name (which must be unique for the target type)
b) select the adapter type
i) OS Command Adapter – single column (one row, one column)
ii) OS Command Adapter – multiple values (multiple rows, one column)
iii) OS Command Adapter – multiple columns (multiple rows and columns)
iv) SQL adapter – SQL queries
v) SNMP adapter – query SNMP agents for MIB (management information base)
vi) JMX adapter – retrieve JMX attributes
c) identify the main metric details
i) indicate if the columns are keys or values
ii) the data type of the value (number or string)
iii) the alert threshold value(s), including if there will be different values based on different key columns
iv) if the alert can be manually cleared
v) how many occurrences must happen in a row before the alert is generated
vi) the alert and clear messages associated with the alert
vii) metric category
d) assign the credentials that will be used to gather the metric data
e) choose the test targets
f) run the tests to validate your metric
g) complete building the metric
After a metric is created, it can also be edited from the same area, by selecting the existing metric and choosing Edit from the actions menu. Metrics can also be converted into a package that would allow them to be exported and imported from one EM installation to another. Additionally metric extensions can be deleted, and privileges can be granted on existing metric extensions to other EM administrators.
Once the metric is created and tested, it must be deployed to the appropriate target(s). This is done via Enterprise>Monitoring>Metric Extensions and selecting Manage Target Deployments Metric extensions can be deployed to single targets, one at a time (this is fine if there are a small number of targets). If deploying to a large number of targets, they can be deployed using monitoring templates.
Converting User-Defined Metrics to Metric Extensions
The ability to convert existing user-defined metrics to metric extensions has also been included in EM 12c Cloud Control, however, this is not done automatically; it must be completed by an administrator. It should be noted, that historical metric data will not be converted, only the actual metric itself.
Converting is done via the Enterprise Manager Command Line Interface (EM CLI) and involves identifying the metric(s) to convert, running the appropriate EM CLI commands, testing the metric extension, publishing it and then deploying the new metric extension. Original credentials for the user-defined metrics will not be converted; new credentials will have to be set for the converted metric extension.
Once the metric is converted, tested and deployed, it is very important to either disable or delete the user-defined metric. Disabling will clear the alerts, stop the collection and testing, but leave the metric metadata intact. Deleting will remove everything.
Some of the EM CLI commands that would be used for doing conversions to metric extensions from user-defined metrics are list_uncoverted_udms, create_udmmig_session, udmmig_summary, udmmig_session_details, udmmig_submit_metricpics, udmmig_retrydeploys, udmmig_request_udmdelete.
In addition to using EM CLI for doing user-defined metric to metric extension conversions, there is a full command line interface for working with metric extensions such as export_metric_extension, get_unused_metric_extensions, import_metric_extensions, publish_metric_extensions and save_metric_extension_draft and the list goes on.
Overall, metric extensions provide DBAs with some powerful additional functionality to be able to truly leverage Enterprise Manager 12c Cloud Control as a single centralized monitoring tool for their entire IT infrastructure.