CONTENTS

RELATED RESOURCES

• Page:
  GDMA (Documentation)
• Page:
  GDMA configuration reference (Knowledge Base)
• Page:
  Release Notes for GDMA 2.7.1 (Documentation)
• Page:
  Release Notes for GDMA 2.7.0 (Documentation)

Controlling poller and spooler status messages

The GDMA profiles contain services called gdma_poller and gdma_spooler. By default, these services will receive status messages from the poller and spooler processes. These messages tell you about how much time the poller is using to perform the checks, and whether the time is excessive. The spooler reports transmission failures, and statistics about how many messages it sent, and if any messages were purged, etc. The state of the services will change, as well, based on whether there is an error to report.

These messages are useful, but can be excessive, especially in large configurations. They should be left on in initial deployments, but after calibration is done, you may wish to curtail their use. or even remove the services. GDMA adds some parameters to allow you better control over these messages:

• Poller_Service="gdma_poller" : This parameter controls the name of the service to send poller messages under, defaulting to gdma_poller. You can change this to another service, possibly combining it with the service for Spooler messages (Spooler_Service) to direct all GDMA messages to one service instead of two.

• Poller_Status=On/Off : This controls whether the poller generates the status messages at all. If you turn it off, that host will not generate these messages. You should remove the gdma_poller service from the host in this case.

• Spooler_Status : This controls whether the spooler sends status messages, and, if so, when. If it's off, no spooler messages will be sent. If it is on, you will get a message each time the spooler runs, which is every 30 seconds by default. If you set it to Updates, it will send you a message only if there has been an error, or something has changed (such as a recovery from an error). GDMA sets this to Updates by default.

• Warning_Threshold, Critical_Threshold=(integer percent) - Applied to the poller, these control when you will get notified that there is a problem with the poller chewing up more than the indicated percentage of its cycle time to perform a single check. That situation is something you probably want to know about, since it means you may be trying to check too frequently, or to check too many services. Remember, GDMA is designed to use very little CPU resources, so it has some built-in waits, and (except in multi-host mode), it actually does not perform checks in parallel. If you are getting close to the limit and you can manage it, you can change these thresholds from their defaults (60 and 80 percent) to cut down on false positives for these services.

Using fully qualified host names

If you manage multiple data centers, or if you have domains of systems that you want to use GDMA on, and want those systems to report all to the same GroundWork server, you may run into a situation where the same short host name is used for more than one host. GroundWork Monitor uses Nagios®, which requires host names to be unique. For GDMA, this presents a problem, as the host name is automatically determined on the GDMA system, so it is possible to have two systems reporting status, and the GroundWork server will only represent them as one.

As long as the domain names differ, however, this can be accommodated by setting up the GDMA hosts in GroundWork Monitor using fully qualified names. Thus a host like server1.foo.com can be distinguished from server1.bar.com, and GroundWork Monitor will be able to tell them apart.

To enable this feature, use the parameter Use_Long_Hostname. Set this parameter to "on" in the gdma_auto.conf file on the GDMA client, and change the host name in GroundWork Monitor Configuration to be the fully qualified name. This will change the way GDMA reports its results for services, and though the first run with the new settings will generate a single spooler messages under the old (short) hostname, subsequent cycles will have the long fully-qualified name used for poller and spooler messages as well.

Forcing determination of GDMA client hostname

The Forced_Hostname directive is used to force determination of the GDMA client hostname to a fixed value. This option is fully supported in the latest GDMA release, on all platforms. Forced_Hostname is an optional directive in the GDMA client config files. The value is the exact hostname (unqualified or fully-qualified, as specified) to be used in place of any dynamic determination of the hostname. GDMA will lowercase the supplied value before use, to correspond to the uniform use of lowercase hostnames in the rest of GDMA.

Additionally, this option is used in support of GDMA auto-registration so that when a GDMA client successfully registers itself with the GroundWork server, the hostname that the server determined was correct for this client gets returned to the client. The client then stashes that hostname as the value of the Forced_Hostname option in the new gdma/config/gdma_override.conf file, so both the poller (which received the hostname from the server) and the spooler (which passively accepts this instruction) know the proper hostname to use even if those components are bounced. This way, the base gdma_auto.conf configuration file is never modified by the auto-registration processing. When the Forced_Hostname is used in this manner for auto-registration, any value, which may have been manually set in the gdma/config/gdma_auto.conf file, will be ignored in favor of the value in the gdma/config/gdma_override.conf file.

Also note that the GDMA auto-registration feature provides special support on the server for forcing the assignment of hostnames to particular values for certain client hosts, via the <hardcoded_hostnames> section of the config/register_agent.properties file.

Known issue and workaround

For a workaround, this must happen on the GDMA client only after the next Commit after the server-side Rename occurs. That way, the new setup will be in place on the server when the updated client reaches for it. Also note that, after the Commit, the administrator should re-build externals, so make sure they are all up-to-date, before making changes on the GDMA client.

• Stop GDMA service
• Delete the forced config and the host named config files
• Start GDMA service

• GDMA client files to delete:
  • gdma/config/gdma_override.conf (which file is supplied to the GDMA client by the GroundWork server during auto-registration, and holds a Forced_Hostname directive specifying the form and content of the hostname that the client is to use when interacting with the server)
  • gdma/config/gwmon_hostname.cfg (which file, named using the precise form of the client hostname which the client should be using, is supplied to the GDMA client by the GroundWork server, and contains host and service externals from the server which are relevant to this client, note this is the actual hostname of the GDMA client, not the literal characters "hostname")

Checking multiple hosts from a single Linux GDMA hostThis is an advanced feature useful when checking clustered hosts, or simply setting up some lightweight monitoring of nearby hosts from a single Linux GDMA.

• The Linux GDMA must be installed using the command-line option --multihost 1
• You need to set up a configuration group for all hosts that will be checked in this way, with a specific build directory for the config files
• You need to create that build directory, and set permissions

Downloading new plugins automatically

The Plugins feature allows administrators to download new plugins and dependencies to the GroundWork server where externals are hosted. Then, based on platform, dependency and externals settings, plugins are automatically applied on selected GDMA client configurations. This feature is disabled by default and can be enabled directly through the user interface. You must selectively enable the download on the agent configurations. See How to allow GDMA to download plugins.