...
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.
NOTE - NMIS9 ships this script in /usr/local/nmis9/conf-default/scripts/webtest.
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 our own internal monitoring is set up to check our own domain, which involves servers outside of our control: We've defined PingOnly-entries nodes with the model set statically to "PingOnly" for the external DNS servers in question, and activated service "opmantek-dns" for them, which looks like this:
Please note that model "PingOnly" by itself is not sufficient to disable SNMP (or WMI) accesses; you also have to change the node configuration option collect to false.
local, custom script
On a system that is under your control, and which runs NMIS you can execute arbitrary scripts to collect service statuses. The example script below checks that the local NMIS server itself has a running BIND DNS server process:
...
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 itself:
MySQL Database
...
MySQL Database
remote, port only
To verify that your MySQL database server is reachable you could define a service to check TCP port 3306, similar to the examples above. Naturally that's not an end-to-end test.
remote, server process status
In addition to the port reachability you can define a service for checking the existence of the "mysqld" process, if you are polling the server in question with SNMP:
remote, custom script
The third, and most comprehensive end-to-end monitoring setup would require a small custom script that actually connects to the server and performs a query on said server. Here is an example of such a script, which would have to be adjusted for your environment (or be changed to accept more command line arguments) and saved as /usr/local/bin/mysqltest:
| Code Block |
|---|
#!/bin/sh
# a small wrapper around the mysql client, which connects to a test database
# and runs show tables; if successful (and there are tables) we call it good
NODE=$1 # passed in, comes from node.host
DBUSER="mytest"
DBPASSWORD="something secret"
DBNAME="testdb"
OUTPUT=`mysql -u$DBUSER -p$DBPASSWORD -h$NODE $DBNAME -e "show tables;"`
if [ $? != 0 ]; then
exit 0 # service bad
elif ! echo "$OUTPUT" | grep -q "Tables_in_"; then
exit 50; # service not fully ok
else
exit 100; # service good
fi |
To use this service test, you'd define a service of Service Type "program", with an appropriate Program path, and with the Program Args being set to "node.host", which would be replaced by the address or hostname of the node in question:
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.
...