About GDMA

Contents

The page describes use cases, modes of operation, and the application design considerations for GDMAs.

1.0 Introduction

A GDMA consists of memory resident programs that perform monitoring checks on individually configurable time intervals and reports the results to GroundWork Monitor. Configuration files containing program directives, including alarm thresholds and other parameters are periodically downloaded from GroundWork Monitor. The agent performs monitoring checks by supplying necessary arguments to small disk resident programs called plugins and then running them with the supplied options. The plugin set provided for the agent is consistent with the plugins distributed with GroundWork Monitor, as well as useful plugins specific to the operating system of the monitored server, for example, VBS or PowerShell plugins for Windows systems.

GDMAs support multiple modes of operation, including installation and configuration, normal operations, and failure modes. Since GDMAs are designed to operate under the control of GroundWork Monitor, there are corresponding functions and features on the GroundWork system that support each of these operating modes, discussed in more detail below. GDMAs can be employed to monitor the single host on which they are installed (single host mode), or to monitor multiple hosts from a single GDMA installed on a single host which is referred to as the multi-host configuration. Multi-host configuration is used with the Windows GDMA to create the Windows Child server and with any supported operating system to provide economical monitoring on customer premises for the Managed Service Providers (MSPs).

Describing the normal operating mode for a single GDMA monitoring a single monitored server helps to introduce the subject.

1.1 GDMA Data and Control Flow

The GDMA consists of two Perl programs; a Poller and a Spooler, the binary program for Send_NSCA, and two or more configuration files. Also included are between 100 and 200 plugins, and a spool file containing monitoring and error messages which are waiting to be transmitted to GroundWork Monitor.

In normal operation, the Poller program reads the configuration file, calls the plugin, and supplies the required arguments to configure it to collect the required metric. It then executes the plugin as a check and writes the results to the Spool File. The Poller then waits until the scheduled time for the next check and repeats the process. Individual checks can be executed each cycle or on a defined multiple of cycles, giving the administrator individual control over each check's schedule.

At defined intervals the Spooler reads the Spool File, calls the Send_NSCA program and transmits one or more of the messages containing monitoring check results to the GroundWork system using the NSCA application protocol. Operation of the Poller, Spooler, and Send_NSCA modules are controlled by parameters contained within the GDMA configuration files.

The default port for NSCA communication is 5667, however, it can be reconfigured to a different port number on both sides of the interface if required.

The configuration file contains a number of error handling and control parameters which are used by the Poller and the Spooler to help ensure the reliable operation of the GDMA, including a subroutine that verifies the validity of the configuration file itself. Error messages are normally written to the Spool file for transmission to the GroundWork system where they can be reviewed and analyzed by system operators using the Event Console application.

Monitoring results reported to GroundWork Monitor are presented as service check results. Host health checks can be performed actively from GroundWork Monitor if access to the monitored server is permitted. If active access is not permitted, an algorithm is used by the GroundWork server to distinguish between service alarm and host failure. Active checks of host health are preferred where permitted for performance reasons.

Routine maintenance of the GDMA configuration is performed by editing the externals text files within the Monarch subsystem on GroundWork Monitor. Either automatically or as an operator action, the Configuration application updates the externals configuration files in the appropriate directory for retrieval.

At regular intervals defined in the configuration files the Poller initiates an HTTP or HTTP(S) connection and looks up the time stamp of the configuration file stored on GroundWork Monitor. If the file on GroundWork Monitor is more recent that the configuration file on the GDMA, the Poller fetches the GDMA configuration file from GroundWork Monitor and replaces the older file on the GDMA with the most recently updated file.

A single Linux GDMA and GroundWork Monitor, which controls it, is illustrated in the following figure.

Figure: GDMA Data and Control Flow

1.2 About Automated Agent Registration

The combined GroundWork Monitor 6.7.0 and GDMA 2.3.0 and newer releases, contain support for a the GDMA client auto-registration capability. This facility is designed to allow hosts monitored via GDMA to be automatically added to the central server, with very little effort by the administrator. Automated Agent Registration was implemented to reduce the administrator's burden when adding many GDMA-monitored hosts to the monitored infrastructure. Many of the simple tasks are highly automated, allowing the administrator to concentrate more on exceptions and the overall monitoring design. 

When Automated Agent Registration is active, each new GDMA client makes an auto-registration request to connect to GroundWork Monitor and receives its marching orders. GroundWork Monitor validates the request, corrects the submitted host attributes if necessary, adds the host to the configuration if it is not already there, builds an externals file containing the details of the monitoring checks the client should run, and finally returns the validated hostname (or error messages) to the client. For more information please refer to Quick Start Auto Registration.

2.0 Use Cases and Application Notes

GDMAs are intended to be used for the following use cases.

3.0 Definitions and Abbreviations

The following definitions and abbreviations of commonly used terms are provided for standardization and reference.

4.0 Description of GDMA Modes of Operation

GDMAs have been designed with modes of operation for installation, auto configuration, configuration maintenance, normal operation, and continued operation in failure modes. The following provides an overview of the major options available for each of these operating modes for the product.

5.0 GDMA Profiles