Database Reference
In-Depth Information
Management Plug-ins
Metric extensions are easy to create and, compared to 10g-style user-defined metrics, are much easier to manage at
scale and provide much more flexibility to users. However, they are still very limited when it comes to monitoring
more-complex targets and metrics.
The power of plug-ins is in new target types that developers can create. Target types provide the already familiar
notion of managed targets for each component of your managed infrastructure. For example, a database instance is a
target and so is a listener. Even Oracle homes are presented as targets in EM12c.
If your application runs on a server as a daemon, and there are ten metrics you want to collect, either you
can define ten metric extensions and deploy all of them or you can define a new target type in a plug-in and then
deploy just one plug-in. Targets also have instance properties that enable configuration of the target according
to its deployment parameters. In contrast, metric extensions are not parameterized at all, so if your application is
configured differently on each server or you are running multiple instances of the application on the same server,
you would have to create a dedicated set of metric extensions for each application.
In addition, plug-ins provide so much more beyond monitoring extensions. They provide full management
capabilities so that plug-in developers can implement actions on targets such as starting and stopping an application
or retrieving logs for analysis on demand or enabling debug mode. Target pages in the console are also fully
customizable. There are ways to define how the new targets can be autodiscovered by EM12c, and many more
features are available such as jobs, reports, configuration management, and compliance standards. You will learn
about some of them in the remainder of this chapter while reviewing the sample plug-ins.
Getting Started with the Extensibility Framework
As mentioned earlier, the EM12c Extensibility framework is not just an add-on feature as it was in the 10g and 11g
versions. Instead, it forms the underlying foundation for all management plug-ins, including those delivered by
Oracle, to monitor its core products such as databases, middleware, applications, and engineered systems.
The Extensibility framework contains everything you need to create new, full-featured target types—from
advanced metric-collection capabilities down to automated discovery, configuration management, jobs support,
and compliance management, as well as full-blown dashboards and fully interactive target-management interfaces.
The Enterprise Manager Extensibility documentation has two guides for plug-in developers:
•
Oracle Enterprise Manager Cloud Control Extensibility Programmer's Guide
is a brief overview
of plug-in concepts and how they all fit together. It's useful to read it in full before going to
the next guide. A title such as
Management Plug-ins Concepts Guide
would reflect the content
better.
•
Oracle Enterprise Manager Cloud Control Extensibility Programmer's Reference
is the
documentation that you will be using all the time. It's structured as a guide rather than a
simple reference, so think of it as the
Management Plug-ins Developer's Guide
.
This section focuses on the practical aspects of plug-in development and details that are not very clear in
the documentation. Because the Extensibility framework has been changed dramatically in EM12c and is not as
broadly used as other end-user functionality, its documentation is not as clear and thorough as the rest of the EM12c
documentation. However, always make sure to check the latest version of the Oracle documentation,
as improvements are released quietly in online documentation from time to time.
Even if you are not planning to develop plug-ins yourself, this section will help you understand some internals of
EM12c, so I recommend you go through it anyway.
Before you dive into the details, let's look at the lifecycle of a plug-in:
•
Design and development
: This is where plug-in developers spend most of their efforts.
•
Packaging the plug-in into an Oracle Plug-in Archive (OPAR) file
: This is a single package that
can easily be distributed.
