EPAgent Plug-ins

The Environment Performance Agent (EPAgent) collects custom metric data and uses plug-ins to send the data to the Enterprise Manager. You can easily integrate any data into the Enterprise Manager by registering stateful or stateless script plug-ins. For example, stateful log-readings scripts, or stateless scripts, such as CPU or OS statistics.
apmdevops106
The Environment Performance Agent (EPAgent) collects custom metric data and uses plug-ins to send the data to the Enterprise Manager. You can easily integrate any data into the Enterprise Manager by registering stateful or stateless script plug-ins. For example, stateful log-readings scripts, or stateless scripts, such as CPU or OS statistics.
EPAgent functionality is included with the Infrastructure Agent (IA). After you install the Infrastructure Agent, you can create and use EPAgent plug-ins without requiring running a separate EPA agent.
You can still deploy the pre-10.7 EPA agent. Starting with CA APM 10.7, the former EPAgent is renamed as the Standalone EPAgent. We recommend that you convert Standalone EPAgent scripts and plug-ins to run using the EPAgent plug-ins using the Infrastructure Agent. However, you can continue to use the Standalone EPAgent scripts and plug-ins as is after some configuration.
If you are creating EPAgent plug-ins for the first time, install and use the EPAgent plug-ins using the Infrastructure Agent.
 
 
EPAgent Plug-in Implementation
The Infrastructure Agent uses the JVM facility to invoke a sub-process and receive STDOUT and STDERR communication channel output streams. The sub-process is any type of script or executable that you can invoke on a command line. For example, a compiled program written in C or Perl script.
By executing a simple PRINT function in the IA EPAgent plug-in format, the application or script in the subprocess communicates with the Infrastructure Agent. Applications or scripts communicate metric data to the Infrastructure Agent by printing to STDOUT as shown in this diagram:
EPAgent Plug-ins Implementation
EPAgent Plug-ins Implementation
The Infrastructure Agent expects the text that it receives using STDOUT to conform to the IA EPAgent plug-in format. The format can be either a simple name/value pair or XML. The application or script sending data to Infrastructure Agent is referred to as an IA EPAgent plug-in. We include a sample plug-in and several default plug-ins that provide detailed metric data. You can also create custom plug-ins.
Errors can be logged through the plug-in standard error channel. This logging allows the Infrastructure Agent to log error output as it would any other errors.
Scripting Environments
The Infrastructure Agent can receive text from any executable entity, including compiled applications. In a sub-process, the most flexible approach is to use a scripting environment, such as Perl, KornShell, or rexx. Interpretative scripting environments provide ease of implementation and often supply libraries or interfaces to real-world data sources. For example, interpretative scripting environments can be relational databases and third-party products. The environments can also be OS subsystems consisting of a process table and file system.
Scripts gather information from a wide variety of sources, such as:
  • Calling a library function or system utility to check the existence of a critical application, such as a database.
  • Scanning and parsing application logfiles to detect application errors.
The flexibility of a scripting environment allows the IA EPAgent plug-ins to gather performance and management information from virtually any source. This diagram shows an example information flow.
EPAgent Plug-ins in Scripting Environment
EPAgent Plug-ins in Scripting Environment
We provide sample IA EPAgent plug-ins, which use Perl. Various platforms provide Perl interpreters and have wide support for data APIs to operating systems, middleware, and third-party products. The sample plug-in includes a set of sample Perl scripts to perform various functions. For example, functions for checking for process availability, obtaining disk performance statistics, and reading HTTP logs. You can extend these scripts to perform other functions. For support with customizations to PBDs, EPAgent scripts, or JavaScript calculators, contact CA APM Implementation Services.
Input from Network Sources
You can use an external entity to send EPAgent-plug-in-format data to the Infrastructure Agent. In this case, you can configure one EPAgent plug-on to listen to a network port for metric data from arbitrary remote systems. For example, in an environment where the agent and scripts footprint is expensive. Another example is when it is inconvenient to install an entire Infrastructure Agent for data collection. To improve these situations, you can configure two ports. One port listens for XML-formatted metric data. The other port listens for data that HTTP requests send, for example, HTTP GET or RESTful requests.
HTTP GET Requests
Requests often sent from common programs, such as
wget
or
curl
, at the command prompt. HTTP GET requests are used for single-metric submissions, and are less efficient than the newer RESTful interface. You can quickly use a browser to illustrate sending metrics. 
RESTful Requests
The Enable the EPAgent Plug-ins RESTful Interface allows metrics to be submitted in batches over a more efficient RESTful PUT operation. 
A RESTful XML format provides maximum flexibility, but is slightly more complex than using HTTP GET requests. RESTful requests require manually managing the socket. An example process is a C++ backend system that provides monitoring information using a network port. Another example is a process that periodically posts data to a web URL.
Supported Plug-ins
The Infrastructure Agent supports both stateful and stateless plug-ins. 
Here are the available plug-in types:
  •  
    Stateful
    These plug-ins are expected to be long-running scripts (daemons). The scripts are to be started when the Infrastructure Agent starts and to run indefinitely. These stateful plug-ins can feed data back to the Enterprise Manager. They can send the data at any time through the standard plug-in output channel. When a stateful plug-in terminates, the Infrastructure Agent restarts the plug-in.
  •  
    Stateless
    These plug-ins are designed to run on a recurring schedule and frequency, which is specified as delay between runs. Stateless plug-ins are expected to be short-running scripts that are intended to collect data. The plug-ins send the data to the Infrastructure Agent through the standard output channel, and terminate. The Infrastructure Agent does not perform special error-checking to ensure that only one stateless plug-in instance is running at a time. You must design your stateless plug-ins to run and complete in a reasonably short time frame.