I have recently been investigating the check_mk agent for Nagios in favor of NRPE for host-level service checks. One of the things that is quite compelling about check_mk is that services are ennumerated by the monitoring server by polling all configured servers rather than defining services explicitly in your nagios configuration. Each server will return information by executing all plugins located in /usr/lib/check_mk_agent/local. This shifts defining what services to monitor to the target hosts themselves.
The output of check_mk plugins differ from Nagios plugins being that instead of exiting with codes 0-3 and printing a status message, all output information is printed to stdout in this format. Meaning- if your plugin doesn’t return any information to stdout, cmk -I (which adds new services to your inventory) won’t detect your service defined by the plugin.
Which leads to a very interesting use of check_mk plugins. Assume for a moment that you were a lazy Linux sysadmin who didn’t want to include logic in your Puppet/Chef/etc manifests to determine which plugins should execute on a given host, and therefore write your plugins everywhere. How can you prevent your MySQL plugins from reporting any information when run on a webserver, for example?
Assuming your hostnames came in the form of TYPE-[0-9]+ (eg: mysql-12.domain.tld), this would prevent the plugin from running on any host unless it were of types type1,type2:
#!/bin/bash if [[ ! $(hostname -s | grep -E 'type1|type2') ]]; then exit 0; fi
If you wanted to be really fancy and enable the plugin if a status file were written out, you could use:
#!/bin/bash if [[ ! -e "/path/to/statusfile" ]]; then exit 0; fi
The benefit of this is the agility of implementing new plugins. Simply write one and deploy it to /usr/lib/check_mk_agent/local on all of your servers and the service will only be enabled where you intend. This is very powerful when you monitor services developed by different groups of contributors, since the cost of entry will be very low.