Some additional information on how it could be achieved:
When run locally, output printed to STDOUT will be sent to the EPA and output printed to STDERR will be sent to the EPA log. So the easiest way to wrap existing script work is create a short wrapper that takes the existing script output and parses it into the correct format (simple or XML; both described below). Then, it prints the formatted output to STDOUT (or to HTTP GET). In this manner, existing scripts can be ported to EPA in a matter of minutes! Libraries for formatting output are available in Perl.
Choosing a Method for Integrating Data :
Data can be sent to the EPAgent in either a simple key-value pairing-referred to as the “simple format”-or a more-robust XML schema (described below).
What is the Simplest Way to Post Data to EPA? (Approach #1)
Use the simple format. Specify one metric name and value per line using the format:
You can also include a reference to a resource segment:
For example (each on one line):
Resource Usage|File IO:diskWrites=37
Apache Errors:LastErrorString=ERROR: Apache shutdown unexpectedly
Simple format guidelines:
• In the “simple” format, the metric name should not contain an equals sign (=). If there is need for an equals sign in the name, use the XML format.
• The value may contain an equals sign (string), and the EPAgent will always parse all characters up to the first equals sign (left to right) as the metric name, and all characters after the first equals sign as the value.
• Any value composed of numeric digits will be interpreted as numeric data and will be reported as an Introscope “IntCounter” type (see below for explanation). Use the XML format to override that type.
• Any value composed of anything other than numeric digits will be interpreted as string data and will be reported as an Introscope “string event” type. (See below for explanation).
How Do I Send XML Data to EPA? (Approach #2)
The XML format of output is much more robust. It connects to the XML network port, reports a snippet of XML as what follows, then disconnects from the port.
<metric type="LongCounter" name="Resource Usage|File IO:diskWrites" value="37" />
<metric type="StringEvent" name="Apache Errors:LastErrorString" value="ERROR: Apache shutdown unexpectedly" />
1. Pick a metric name, using ‘|’ characters to create “turny knobs” in the Investigator tree. This will be your “name” attribute.
2. Pick a “type” of metric:
a. PerIntervalCounter (Useful for rate metrics, like “miles per hour” or “errors per interval”; resets to zero at each new interval.)
b. IntCounter (Useful for tally metrics, like “msgs in queue”, and does not change until a new value is reported.)
c. IntAverage (Useful for response times, like “average time in seconds”. Do not calculate the average yourself. Just report all the applicable metrics (like in a loop) and the calculation will be performed automatically at the end of the interval.)
d. LongCounter (Same as above, but for very large numbers.)
e. LongAverage (Same as above, but for very large numbers.)
f. StringEvent (Use to report string values, like “startup command-line” or a log entry.)
3. Report a value for the metric
Create StringEvent metrics somewhat sparingly! These are the costliest metrics for Introscope to handle, and are NOT stored by SmartStor, so you will only see the current value. If you were to use thousands of these metrics, the performance of your EM could be impacted.
NOTE: EPA takes string or integer data only. If you have floating-point data, it should be converted to integer values prior to sending to EPA.
This document was created to help with your customization. Any further help needed related to this Knowledge Document or others customizations must be addressed by CA Professional Services, since this is out of CA Support scope.