Database Reference
In-Depth Information
</ColumnDescriptor>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="SQL">
<Property NAME="STATEMENT" SCOPE="GLOBAL" OPTIONAL="TRUE">
SELECT ROUND (c.open_cursors / p.value * 100) open_cursors_pct
FROM (SELECT sid, COUNT (*) open_cursors
FROM v$open_cursor
GROUP BY sid
ORDER BY 2 DESC) c,
v$parameter p
WHERE p.name = 'open_cursors' AND ROWNUM = 1;</Property>
<Property NAME="MachineName" SCOPE="INSTANCE" OPTIONAL="TRUE">MachineName</Property>
<Property NAME="Port" SCOPE="INSTANCE" OPTIONAL="TRUE">Port</Property>
<Property NAME="SID" SCOPE="INSTANCE" OPTIONAL="TRUE">SID</Property>
<Property NAME="UserName" SCOPE="INSTANCE" OPTIONAL="TRUE">UserName</Property>
<Property NAME="password" SCOPE="INSTANCE" OPTIONAL="TRUE">password</Property>
<Property NAME="Role" SCOPE="INSTANCE" OPTIONAL="TRUE">Role</Property>
<CredentialRef NAME="SQLCreds">
</CredentialRef>
</QueryDescriptor>
</Metric>
If you find it challenging to create metric definitions in XML from scratch, you can start by creating a metric
extension as a prototype and then simply pick up the XML definition from the repository, copy it into your target type
metadata definition XML file, and modify it as needed. The raw XML definition gives you much more flexibility.
EM12c Fetchlets
EM12c comes with more than a dozen documented fetchlets. Here is a brief summary of available fetchlets:
OS Command fetchlets : This family of fetchlets lets you run operating system commands
and scripts and pass metric values as the output. You have already looked at examples,
and the three OS Command fetchlets have the same functionality as the OS Command
adapters you looked at in the “Metric Extensions” section. The OS commands are run by
an agent using the same OS user that's running the agent itself on the host where the agent
is installed. To ensure platform compatibility as much as possible, I recommend that you
use Perl scripts as commands and use Perl that's distributed with the agents. The scripts
and any dependencies can be added to the plug-in and can be distributed when a plug-in
is deployed on the agents. Note that if dependencies cannot be simply copied, and need
compilation or any other configuration on the host, then such dependencies will likely
need to be preinstalled on the hosts running agents. This complicates deployment and
should be avoided. For example, if you want to connect to a non-Oracle database from a
Perl script using DBI, you need to compile required DBD modules such as DBD::MySQL,
which needs to be done manually on each agent on the host before the plug-in is deployed.
Thus, using Perl native modules is preferred (such as Net::MySQL in this example—this is
what I use for the MySQL plug-in).
 
Search WWH ::




Custom Search