SURVIVOR: About Check Modules
What Check Modules Do Module Types Module Data Adding Custom Modules
What Check Modules Do
Check Modules evaluate the status of services that run on hosts.
Module Types
Check Modules may be two types of executables: 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. Scripted. These are written in a language such as Perl or shell. More portable than compiled modules, they may still require tweaking to run. Check Modules may run in one of two locations: Scheduler These run on the host that runs the survivor scheduler. Generally, they take advantage of network protocols to perform service checking. 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.
Module Data
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.
Adding Custom Modules
2. 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: 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/`. 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. $Date: 2006/11/19 18:10:30 $ $Revision: 0.11 $ | keywords