Table Of Contents

Previous topic

Agent Architecture

Next topic


Monitoring Configuration

Configuration Sources depicts the Abilisoft Agent in an autonomous environment and the three possible methods of acquiring its configuration, the Manifest.


Configuration Sources

The Abilisoft Agent can operate as part of the Abilisoft Enterprise suite or autonomously. In either operational mode the Agent behaves according to the configuration settings defined in its Manifest. The Manifest is the collective name for a set of related XML documents that define the behaviour of the Agent and the data it should gather. The Master Manifest is a root document that publishes the sub-manifests that must be acquired and the transport mechanism by which they should be acquired. Supported transport mechanisms for getting manifest data include:

  • File-system. A local or remote file system path is specified.
  • HTTP. A URL is specified.

The Master Manifest transport is implied in the URI defined in the agent settings file.

The following is a basic example of a Master Manifest:

<?xml version="1.0" encoding="utf-8"?>
<Manifest name="Abilisoft"
          updated="2008/09/23 05:05:47"
          effectiveFrom="2008/06/23 13:00:00"
  <xi:include href="defaultTrapDef.xml"/>
  <xi:include href="defaultSMTPDef.xml"/>
  <xi:include href="sshMonitor.xml"/>

The important attributes of the <Manifest> element include name and updated. The updated field controls if the agent will load this manifest in place of the one it has. Sub-manifests can be acquired over different transports. Once the Agent has loaded the master manifest it will load sub-manifests. This allows a large number of agents with different but overlapping configuration requirements to be managed more easily. The manifest can be any combination of monitoring definitions.

Manifest Structure

The agent has a zero configuration monitoring feature. It detects the server CPU’s, disks and important files and monitors them by default. Captured data can be acquired via the AAPI. Default, enabled monitors include cpuUsage (all instances), diskUsage (all instances), memUsage and swapUsage. Default observations (thresholds) are set up for each but no actions are defined. Therefore, the manifest required can be minimal. The following shows a manifest in its simplest form:

<?xml version="1.0" encoding="utf-8"?>
<Manifest name="Abilisoft"
          updated="2008/09/23 05:05:47"
          effectiveFrom="2008/09/23 05:05:47"

A manifest can be structured in a number of ways. The Master Manifest (i.e. the manifest specified by the MasterManifestUri setting) can contain all the monitoring behaviour configuration, XInclude statements to incorporate sub-manifests or a mixture of both. Only the Master Manifest can contain the <Manifest></Manifest> elements. XInclude directives can be used anywhere, as long as the included XML fragment conforms to the DTD schemata (see Appendix F - DTD).

All monitoring configuration is defined in terms of Component definitions which in turn specify Sample definitions. A <Component> element contains the component definition and can exist as a child of the <Manifest> element in the Master Manifest or as a child of the <Fragment> element is a sub-manifest. A <Monitor> element can exist as a child of a <Component> or a <Fragment> element. Some Components are built in but you can easily define your own using the monitors available. Example Manifest Structure below depicts a possible manifest structure.


Example Manifest Structure