...
Here is a configuration snippet for this level of monitoring, for the standard web ports 443 and 80, which you would activate for the server that you want to test:
Server Process
If SNMP is enabled for the system in question, if NMIS is polling that system and if the system and its model supports the Host Resources MIB, then NMIS can check process statuses and verify the existence of a specific process. The Service Type must be "service", and the name of the process must be given as Service Name, and you need to activate the service for the node that you want to test.
For a CentOS box with Apache 2.2.x we'd be using the following service definition, which checks for processes named "httpd":
SAPI-script based
NMIS can also do a limited amount of interaction with a TCP-based service using SAPI scripts. Example scripts for POP3 and basic HTTP are shipped with NMIS in /usr/local/nmis8/conf/scripts. The default http script connects to the Web server in question and attempts to download the root index URL "/"; if this request succeeds or returns an HTTP redirect, then the service is considered to be ok.
To enable this kind of monitoring, you need to define the service with the Name matching the script file name. The Service Name can be a text of your choice, but the Service Type must be "script", and you must activate that service for the node that you want to communicate with:
end-to-end using a custom program
If you need more precise interaction with your web service than the SAPI scripts can provide (e.g. SSL/TLS or cookies or the like), then you'll need to use a custom script. NMIS 8.5.4g ships with an example script of that type in /usr/local/nmis8/install/scripts/webtest, which should to be moved to a directory meant for binaries (e.g. /usr/local/nmis8/bin or /usr/local/bin/) if you want to use it.
The example script downloads a web page (optionally following a number of redirections) using http or https, and optionally checks that the document content matches a given regular expression. You need to define this service with Service Type "program", provide suitable Program settings for the program and activate the service for the server that you want to test (but please note: the custom program will always be run locally on your NMIS server!)
Here is how we verify that the Opmantek website is up and running: this downloads the page using https, then looks for the phrase "Opmantek Products":
DNS
remote, port only
NMIS can monitor the accessibility of TCP and UDP ports (using the NMAP tool), which in the case of DNS would give only a rough indication of whether the DNS server is reachable at all.
...
To verify the general operation of a remote DNS server, you can use the service 'dns' that's built into NMIS. This service will make a DNS request to the server in question and then triggers outage alerts based on getting a DNS record back or not , (and also captures the response time).
Here is how our own internal monitoring is set up to check our own domain, which involves servers outside of our control: We've defined PingOnly-entries for the external DNS servers in question, and activated service "opmantek-dns" for them, which looks like this:
...
To use this, save the script somewhere NMIS can access it (as /usr/local/bin/bindpresent for example), then configure NMIS with this service of type "program" and activate the service for the NMIS server in questionitself:
MySQL Database
TBA
UPS Status
custom scripts
Cheaper UPS systems that don't have builtin networking or SNMP capabilities can be monitored by NMIS as well, as long as there is some sort of management infrastructure that supports querying the UPS status. In this example we're checking two UPS systems that are connected to our NMIS server via USB cables, where the NUT (Network UPS Tools) suite takes care of the interfacing.
...
For our UPS systems we first make use of NMIS' builtin SNMP-based process status monitoring, which checks that there is at least one active process with a given name (here 'upsd'), and then added the per-UPS status checks with the UPS names passed to the upstest script. This example setup requires that the UPSs are connected to the NMIS server itself, but NUT could of course be accessed over the network.
Here is our service definition:
