Monitoring Remote Hosts with GDMA in Multihost Mode


The GDMA is an agent you can deploy on a host running Linux, Windows, Solaris or even AIX. As useful as that is, sometimes you need to monitor hosts that you don't really have access to, or can't install an agent on for contractual or practical reasons. In that case, you can still monitor them over the network using the GroundWork server's Nagios installation to probe them for available ports, use SNMP, or even WMI (in the case of Windows). Still, what if they are remote, and you don't have direct access to them from the GroundWork server? What if you can install GDMA on a host that is remote, but only one? 

This situation can be handled by placing the one GDMA you can install remotely in Multihost Mode. In this mode, GDMA will download all the configurations for monitoring not only itself, but a set of (potentially hundreds of) other hosts that it can access over the network. It will then happily schedule all the checks of all the hosts in a spread schedule with concurrency, and send you the results back, all from one GDMA. It's like having a mini-GroundWork server on the remote site (with some limitations, of course). 


Install GDMA in Multihost Mode

The first step is to install GDMA in multihost mode. To do this, first install GDMA normally, but don't use auto-setup or auto-registration. In fact, don't start the GDMA after installing it. Instead:

  1. Edit the gdma_auto.conf file on the GDMA host you want to be in Multihost Mode. Use the system editor of your choice, e.g., vim in Linux or Wordpad in Windows. 
    Change the following directives to these values: 

    Enable_Auto = "off"
    Enable_Auto_Setup = "off"
    GDMA_Multihost = "on"
  2. Change the following directives to reflect the name of the Multihost GDMA. For example, if this is a Linux host, you might use "uchild1" as the designation, and the spooler service as "unix_child_spooler", like so: 

    GDMAConfigDir = "gdma/uchild1"
    Spooler_Service = "unix_child_spooler"

    Whatever name you choose, make it unique to this particular host. You can also use the hostname if you like. Note the name you use for later steps. Any other directives (https, certificates, choice of transport) can be as your network and system policies require.

  3. Start the GDMA.  

Add a Monarch Group

  1. Log in to the GroundWork server as an administrative user, and go to Configuration > Nagios Monitoring > Groups.
  2. Click New, enter a group name as the name of the config directory directive above (e.g., uchild1), click Add and set the following:
    • Group type: Other
    • Build folder: /usr/local/groundwork/monarch/htdocs/gdma/uchild1 (using whatever you named the group as the last level, e.g., uchild1)
    • Nagios etc folder: Leave field blank
  3. Save the group. 

Add the Multihost GDMA host

You must add the host you installed the multihost GDMA on explicitly to the configuration. We recommend you use a default gdma profile for the host type. Using the host wizard is easiest.

Also add this host to the group you created:

  1. Go to Configuration > Nagios Monitoring > Groups, expand the group you created. 
  2. Click Details, then the Hosts tab. 
  3. Select the host in the list and click Add hosts
  4. Save the Group.

Add Remote Hosts to the Group

Add all the remote hosts you want to monitor to the system, using gdma profiles,, either the defaults or your own design. Make sure the host and service externals are correct.  You may wish to disable active host checks. Using the Host wizard is easiest. 

Add these hosts to the group as well. 

At this point, you can build externals and commit. The externals will be placed in the build folder for that Multihost GDMA host, and the GDMA will download and run them all, specifically. 



  • The ability to run checks against multiple hosts from a single GDMA host
  • The ability to allow traffic from a single host to contain check results from multiple hosts
  • You can run potentially hundreds of instances of GDMA Multihost, covering potentially thousands of systems in a highly distributed architecture. 


  • Access to the hosts checked is over the network connection, and so won't have the detail of a locally run check by the GDMA. 
  • The overhead of running the additional checks on the Multihost GDMA may affect any workloads that system may run.  

Related Resources