• What Check Modules Do
• Module Types
• Module Data
• Adding Custom Modules

Check Modules evaluate the status of services that run on hosts.

Check Modules may be two types of executables:

1. Compiled.
   These are built using a compiler, generally at the time when the package is built. Written in a language such as C or C++, they may take advantage of existing APIs but may require tweaking to build on varying platforms.

2. Scripted.
   These are written in a language such as Perl or shell. More portable than compiled modules, they may still require tweaking to run.

1. Scheduler
   These run on the host that runs the survivor scheduler. Generally, they take advantage of network protocols to perform service checking.

2. Remote
   These run on the host being checked, via the transport modules and the remote gateway. For portability, remote modules should generally be scripted. Note that some modules may not be indicated to run via remote gateways, but may work that way anyway.

Check Modules are provided an XML document containing a SurvivorCheckData element, which may include arguments as configured in check.cf.

Modules generate an XML document containing zero or more SurvivorCheckResult elements.

All Check Modules must conform to the Check Module Specification, otherwise they may not interact correctly with the scheduler.

It is important for check modules to be properly parallelized, to prevent one non-responsive host from interfering with the checking of other hosts. There are two methods for easy parallelization:

1. libcm
   Compiled C++ modules may be built to use libcm, a multithreaded library to parallelize checking. The object interface is defined in include/libcm.H. As a starting point, see the sample test modules in src/modules/check/test/.

2. Survivor.pm and Survivor/Check.pm
   Perl modules may be written against Survivor.pm and the related Survivor/Check.pm modules, which can detect if they are running under a multithreaded version of Perl, and can automatically parallelize via fork if threads are not available. As a starting point, see the sample test modules in src/modules/check/test/.

   For information on these modules, run

        % perldoc src/modules/common/Survivor.pm
        % perldoc src/modules/common/Survivor/Check.pm
        

Check Modules may be run either on the scheduler host, or directly on the host being monitored. Modules run directly on the host being monitored must work with the transport modules, which works with the remote gateway.

Check Modules must require their arguments to be typed.

Check Modules may track the duration of check execution and include this information in the check result document. This functionality is handled automatically by libcm and Survivor/Check.pm, but can be disabled via cm_measure_duration(false); in the former and $self->MeasureDuration(0); in the latter. Note that libcm uses millisecond resolution, but Check.pm (due to limitations in Perl) uses second resolution. See also the technical document on duration measurement.

For assistance in testing Check Modules, the XML Maker utility may be useful. Additionally, the special module arguments debugfile (type file) or debugsyslog (type boolean) may be used to enable debugging.

Important: Please see the license for this package to see if custom modules are subject to the same license.