6.1
Table Of Contents
- Endpoint Operations Management Agent Plug-in Development Kit
- Contents
- About the Endpoint Operations Management Agent Plug-in Development Kit
- Introduction to Plug-in Development
- The Role of the Server and Agent in Plug-ins
- Technical Overview
- Plug-in Implementations
- Using Support Classes to Simplify a Plug-in
- Writing Plug-ins
- JMX Plug-in
- Script Plug-ins
- SNMP Plug-in
- JMX-Based Management
- Auto-Discovery of JMX Resources
- Configuration Properties for JMX Monitoring
- Creating a Custom JMX Plug-in
- Defining Service Types to Provide Management via Custom MBeans
- Defining an ObjectName to Access Custom MBeans
- Defining Configuration Properties to Appear in the User Interface
- Defining and Gathering Metrics
- Specifying the Availability Metric for MBeans
- Implementing Control Actions
- Defining the Server Auto-Inventory Element
- Discovering Custom Properties
- Running and Testing Plug-ins from the Command Line
- Using Auto-Discovery Support Classes in Plug-ins
- Working with Plug-in Descriptors
- Plug-In Support Classes
- Index
Example: Complex metric Tag
<metric name="Availability"
alias="Availability"
template="sigar:Type=ProcState,Arg=%process.query%:State"
category="AVAILABILITY"
indicator="true"
units="percentage"/>
Using Templates to Collect Metric Data
Metric templates enable plug-ins to mix and match sources for the data they collect.
The measurement template uses an extended form of a JMX ObjectName,
domain:properties:attribute:connection-properties.
boss.system:Type=ServerInfo:FreeMemory:naming.url=%naming.url%
where
domain jboss.system
properties Type=ServerInfo
attribute FreeMemory
connection-properties naming.url=%naming.url%
This is the extension to the JMX ObjectName format. Arbitrary properties are generally used to connect to the
managed server. In this example, JBoss JMX requires a JNP URL (specified here as a variable, indicated by
"%": %naming.url%). The variable is given a value by the MeasurementPlugin.translate method, using the
inventory property value for this server instance.
Using Support Classes to Simplify Metric Collection
In a template, the domain can be used to invoke an HQ-provided support class for handling common sources
of metrics, such as Process Information, scripts, SQL Queries, and Network Services. You can see this use of
templates in many of the plug-in examples.
A template must be written in a way that the underlying support class can recognize, specifically, the order
and kinds of values being passed to it.
In script plug-ins, the exec domain, in the script support class, is common. It is invoked using the arguments
file (the file to execute) and possibly timeout (to make the timeout value explicit, for easier troubleshooting,
instead of using the default value) and exec (to specify permissions). For example:
template=exec:timeout=10,file=pdk/work/scripts/sendmail/hq-sendmail-stat,exec=sudo:${alias}
There is also a large class of "protocol checkers" that you can use in a template for easy collection of protocol
metrics, for example, for HTTP or SMTP. You can use a protocol checker for any of the platform services
that are defined in the Endpoint Operations Management agent.
Setting a Plug-in to Auto-discover Resources
The Endpoint Operations Management agent has already defined an autoinventory plug-in for several
collection methods. Generally, you only need to call it in your own plug-in.
Auto-discovering a Server Resource
You can specify auto-discovery of a server by adding the following to line to a <server> tag.
<plugin type="autoinventory" class="org.hyperic.hq.product.jmx.MxServerDetector"/>
Chapter 2 Using Auto-Discovery Support Classes in Plug-ins
VMware, Inc. 45