Database Reference
In-Depth Information
relation or string matching operator. In Listing 10-13,
LT
means
less than
and
GT
means
greater than
. String conditions
include
CONTAINS
for a substring match and
MATCH
for a regular expression match. Section 3.5.5 of the
Extensibility
Programmer's Reference
has a full list of operators. Note that operator codes must be in uppercase.
The default warning and critical thresholds can be defined as part of a
Condition
element by using the attributes
WARNING
and
CRITICAL
. Just like a collection schedule, the thresholds can be modified by an EM12c user. Both
warning and critical thresholds are optional and often left undefined if there is no value that is a reasonably good
default. The value
"NotDefined"
is the same as defining no value at all, as shown in Listing 10-13 for the
"non_nice"
column condition. I prefer to just skip the definition to keep the metadata definition clean, just as there is no
WARNING
threshold for the
Status
column of the
Response
metric. You can also see that it's possible to define a column-specific
alert message and include the column name and latest value as well as thresholds by using a placeholder variable
such as
%columnName%
. Because the percent sign (
%
) has a special meaning, you should use a double percent sign
(
%%
) to include a real percent sign in the message. In the same fashion, you can define a custom message generated
in EM12c when a condition is cleared. It's also possible to specify the attribute
OCCURRENCES
to set the number of
consequent occurrences of the condition before an alert is raised.
As long as a condition operator is specified in the target default collection file, thresholds as well as the number
of occurrences can be customized in the EM12c console. The operator itself, however, cannot be changed. Thus, pay
special attention to selecting the right condition operator.
Packaging the Plug-in
Now you know about all the components of the minimal EM12c plug-in, you also need to place the OS scripts called
by metric collection fetchlets defined in target type metadata. I recommend writing OS scripts in Perl and use the
version of Perl that's installed with Oracle Management Agents. This is the most platform-independent approach
(though the example Oracle provides works only on Linux for the sake of simplicity—the Perl script simply calls
some OS utilities to collect data). Scripts are placed in the agent-side staging area in the
scripts
directory, and a
subdirectory with the same name as the target type is created. So, in our example, the
data_collector.pl
file is
placed in
<stage>/agent/scripts/sample_host1
where
sample_host1
is target type.
With all the components and scripts in place, you can now package the plug-in archive. You can run plug-in
validation before packaging, just as in Listing 10-7 earlier. However, plug-in creation includes a validation step, so it's
not necessary to run the validation as a separate step.
When deploying sample plug-ins, I used the script
build_sample_plugin.sh
, which is nothing else but a small
wrapper for the
empdk create_plugin
command. The full command for deploying the plug-in is as follows:
empdk create_plugin -stage_dir <stage_dir> -out_dir <output_dir>
Two mandatory parameters define the location of the staging directory and the output directory where the OPAR
file is produced. See of the
Extensibility Programmer's Reference
(Chapter 13, Section 13.4) for details on optional
arguments of
empdk create_plugin
.
During packaging of the plug-in, EDK creates additional files in your staging area that are packaged into the plug-in
archive. For example, it creates PL/SQL code importing the target type definitions into OMS during deployment.
You don't need to worry about them or maintain them; they are re-created each time you create the plug-in archive.
The created OPAR file is used to distribute the plug-in to other users (EM12c administrators) whether you created
it for your own organization or for external users, and whether it's a free plug-in or a commercial one. The deployment
procedure is the same as that used in the deployment of the sample plug-ins outlined earlier and also described in detail
in the
Extensibility Programmer's Reference
(Chapter 13, Sections 13.5 and 13.6). The end-user documentation on plug-in
management is available in Chapter 22 of the
Oracle Enterprise Manager Cloud Control 12c Administrator's Guide
(refer
to the “Importing Plug-In Archives” part of Section 12.4.3.2 if you distribute an OPAR file directly to end users).
For the three host sample plug-ins, all steps have already been done earlier, so the initial samples are already
deployed and targets created. Note that the
oracle.samples.xsh1
plug-in implements a few more features that you
will look into later in this chapter, but what you've learned so far is pretty much the core of any plug-in with new
target types.
