Database Reference
In-Depth Information
■
an example of using input credentials can be seen in the
Oracle Enterprise Manager Cloud Control 12c
Administrator's Guide
(Chapter 8, “Metric extensions,” section 8.4.1).
Note
Now let's look at each of the OS Command adapters.
OS Command—Multiple Columns
The OS Command—Multiple Columns adapter is the one that you will likely be using most often. The output from
the command is parsed by the adapter so that each line is a single row, and then each line itself is tokenized into
multiple values. The adapter splits lines correctly, whether the end of line is marked in Unix-like format (single LF)
or Windows (CR+LF).
The adapter allows the use of a “Start With” prefix to filter out the lines of output that do not contain metrics.
This is a good practice, preventing potential output noise from interfering—for instance, warnings that you didn't
expect or just want to ignore. The widely accepted standard for the prefix is
em_result=
. Listing 10-4 shows an
example of output.
Listing 10-4.
Sample Output from OS Command Using the
em_result=
Prefix
em_result=<metrics line 1>
This line is ignored
em_result=<metrics line 2>
If em_result= is not at the start of the line, it's ignored too
em_result=<metrics line 3>
Note that leading and trailing spaces in the prefix are significant and are not truncated.
The content of the line after the prefix is then tokenized into columns by using a simple delimiter string.
The default (and commonly used) delimiter is the pipe symbol (
|
). However, if your column content might contain
that character, you can use any other delimiter and even a multicharacter string to make it truly unique, such as
{=-DELIMITER-=}
so that a line like this is parsed correctly into three values:
em_result=Some common separators are | , % ;{=-DELIMITER-=}123{=-DELIMITER-=}456
Spaces have a special meaning in the delimiter strings. First, the leading and trailing spaces are truncated and
ignored. The rest of the spaces seem to be splitting the delimiter string into multiple delimiters, but they are applied
very inconsistently, so it's difficult to predict the end result. I've tried to create a delimiter to parse lines with
comma-separated values and optionally enclosed in double quotes, but I couldn't come up with a reliable delimiter
string. I suspect the code simply never was meant to deal with spaces in the delimiter. The documentation says
nothing about handling spaces, and their handling seems to be unreliable, so I strongly recommend avoiding spaces
in your delimiter strings at this point.
One final note about spaces: the spaces in the collected values are not truncated when they are stored in the
repository. However, the EM user interface displays them with leading and trailing spaces truncated. If you are setting
conditions on the text columns such as
CONTAINS
, then leading and trailing spaces are significant in both condition
strings and collected metric values, so be careful. I recommend avoiding leading and trailing spaces, if possible, because
you don't see them in the user interface, but they are there. (Just check the repository view
MGMT$METRIC_CURRENT
,
for example.)
When defining adapters, you need to define named columns and their attributes. You already went through the
preceding examples, so let's just touch on the distinction between data columns and key columns.
