Database Reference
In-Depth Information
that can serve as “helpers” to form fetchlet's pre-defined configuration properties. For example, the
perlBin
and
fake
properties are referenced from the command property.
The
SCOPE
attribute of a
Property
element defines the context where the property value is resolved. The following
are the most important
SCOPE
options:
GLOBAL
: The value is the content of the
Property
XML element with placeholder variables
that are resolved to the properties of the current
QueryDescriptor
element. In our example,
the
command
property has scope
GLOBAL
with the value
%perlBin%/Perl
. Placeholders
within
%%
are substituted with the property values of the current
QueryDescriptor
element, such as
perlBin
. Another example of the
GLOBAL
property is the
script
property
that references
scriptDir
and
fake
properties.
GLOBAL
scope is also used for constant
definitions such as the
delimiter
property. The name
GLOBAL
might be misleading, but just
remember that the scope is the current
QueryDescriptor
element.
SYSTEMGLOBAL
: This value is resolved in the context of the
emd.properties
configuration file
in the directory
$AGENT_HOME/sysman/config
. The content of the
Property
XML element is
the name of the variables from the
emd.properties
agent configuration file. For example,
emd.properties
contains
perlBin
, defining the path to the Perl executable. This is useful
if Perl scripts are used to gather metric values, so you can always use the Perl distribution
that's installed with the management agent rather than hoping that a compatible system
version of Perl is installed. Another useful
SYSTEMGLOBAL
value is
scriptsDir
, which points
to the path where the scripts for all plug-ins are installed in a subdirectory with the same
name as the target type ID.
INSTANCE
: This value is resolved in the context of the target instance (that is, the values
of instance properties that are defined when the target is configured). These values
are different for each target instance. In our example, you can see how
USE_FAKE_DATA
is referenced, but not
sample_host1_username
or
sample_host1_password
. If metric
collections were actually using these properties, they would have been passed to the
connection script one way or another.
ENV
: This is the value taken from the environment variable. For example, if your monitoring
script requires a special binary to be installed on the server, and that binary is not
distributed with the plug-in, you can specify a path to that binary via a certain environment
variable set before the agent is started. For example,
<Property NAME="mypath"
SCOPE="ENV">MYSQL_PATH</Property>
will take the value of the environment variable
MYSQL_PATH
as the value for the property
mypath
so that you can later refer to it as
%mypath%
from the
command
property.
It's possible to set environment variables before the command is run—whether to define requirements or
pass parameters. If command-line parameters contain special symbols, they might be handled differently on
different platforms. Environment variables seem to be passed reliably on all platforms, including Linux, Windows,
and Unix. Passing credentials and other sensitive information via environment variables could be more secure
than via the command line, which is often easily observed by any logged-in host user. However, some platforms
may expose the content of environment variables of a process to other users, as Linux does via the
/proc
filesystem. Later in this chapter, you will learn about monitoring credentials, which is a more secure way to pass a
login and password to a script.
