Database Reference
In-Depth Information
I found it useful to use a trick when working with cumulative counters that can be reset from time to time
(just as instance statistics are reset at instance restart), resulting in a negative difference, which in turn will
produce huge negative ratios. Instead, such collections should be skipped. This is essential to make your metric
collections trustworthy.
COMPUTE_EXPR
supports a conditional operator in the form of
{cond} ? {true value} : {false value}
. If a
previously collected value is higher than the current value, then I should return an empty value, which I would prefer
instead of 0 since it tells me that the collection is simply missing. Because
COMPUTE_EXPR
doesn't like to take a
NULL
(no value) in the formula, I use a trick to produce an empty value for the column: I cause an exception dividing by 0.
So my formula looks like
_val > val ? 1/0 : (val - _val)/__interval
. I learned that EM12c catches the exception
and assumes the column value is empty. This has been working since at least Grid Control 10.2 and still works in
12.1.0.2. However, test your metric collection with any new patch sets; because this behavior is not documented, there
is no guarantee it won't change. I would love to have an explicit expression to return a
NULL
-like value.
Key Columns
Just as in metric extensions, it's possible to declare some columns as key columns and process multiple rows returned
from the fetchlet as multiple rows in the table. Listing 10-17 demonstrates an example of a metric for statistics per
CPU, where the CPU number is defined as a
KEY
column. The result is the same as with key columns in metric
extensions. The complete XML fragment is in the target type metadata of the
sample_host1
target type.
Listing 10-17.
Key Columns Definition Example
<Metric NAME="CPUProcessorPerf" TYPE="TABLE">
<TableDescriptor>
<ColumnDescriptor NAME="CPUNumber" TYPE="NUMBER" IS_KEY="TRUE"/>
<ColumnDescriptor NAME="CPUUser" TYPE="NUMBER" IS_KEY="FALSE"/>
...
</TableDescriptor>
...
</Metric>
Dynamic Properties
I have covered only static instance properties that are defined by EM12c users when adding target instances. However,
there is a mechanism to collect properties dynamically that can later be used in the plug-in configuration for metric
collections. For example, you might want to collect the target version or the platform it's running on so that you can
then collect platform-dependent metrics (often Linux and Windows platforms are handled differently, for example).
You can also use dynamic properties to display on the target home page (something you will learn about later).
Just like static instance properties, dynamic properties are defined under
InstanceProperties
as a
DynamicProperties
element. The element structure is similar to that of
Metric
element but it doesn't have a
TableDescriptor
. The list of properties is defined in the
PROP_LIST
attribute as a semicolon-separated list (for
example,
"prop1;prop2;prop3"
). It also has a special format
ROW
instead of
TABLE
used normally for metrics. Just like
a metric,
DynamicProperties
includes a
QueryDescriptor
defining the fetchlet used to collect the properties listed in
PROP_LIST
. The fetchlet should return just one row with the values corresponding to the
PROP_LIST
attribute. Listing 10-18
shows a shortened snippet of a dynamic property from the
sample_host1
target that we've been using as an example
so far.
