As of v4.0.0-beta.3, Check NetApp-REST ships a new binary called check_netapp. It bundles all 20 ONTAP-REST checks — volume, aggregate, snapmirror, disk and so on — as subcommands of a single executable, in addition to the familiar individual check_netapp_* binaries.
Why a single binary?
Each check_netapp_* binary is a statically linked Go executable of around 10 MiB. With 20 of them in the package, that adds up to roughly 200 MiB on disk — for what is, under the hood, largely the same runtime and shared library code repeated 20 times.
check_netapp builds all of the same checks from one shared codebase into one executable of about 10 to 15 MiB in total. For monitoring hosts where disk space is tight, or for container images built from our tarball, that is a meaningful reduction.
Nothing changes unless you want it to
The individual check_netapp_* binaries are not deprecated. Both forms are shipped side by side and will continue to be supported — there is no migration deadline and no removal planned. If you don’t care about the disk space, you can simply ignore check_netapp and keep using your existing configuration unchanged.
For every check, check_netapp <object> … behaves identically to check_netapp_<object> …: the same flags, the same defaults, the same output, the same exit code, the same license check. For example:
check_netapp_volume usage -H filer01 --storedir /usr/local/monitoring-plugins.pro/netapp-rest/var/store
check_netapp volume usage -H filer01 --storedir /usr/local/monitoring-plugins.pro/netapp-rest/var/store
produce byte-identical output. Nested subcommands work the same way, e.g. check_netapp aggregate free, check_netapp node service-processor or check_netapp snapmirror metric lag-time.
What changes if you do switch
To actually benefit from the smaller footprint, you need to delete the check_netapp_* binaries from bin/ and keep only check_netapp. Since the check is now invoked as an argument instead of being baked into the executable name, your monitoring configuration needs a small adjustment.
Nagios / Icinga1 style commands.cfg: our example configuration already passes the check name as $ARG1$, so the change is a one-character edit — drop the underscore and add a space:
define command {
command_name check_netapp_rest
- command_line /usr/local/monitoring-plugins.pro/netapp-rest/bin/check_netapp_$ARG1$ \
+ command_line /usr/local/monitoring-plugins.pro/netapp-rest/bin/check_netapp $ARG1$ \
-H $HOSTADDRESS$ $ARG2$
}
Icinga2: the CheckCommand objects we generate reference the individual binaries directly, e.g. PluginContribDir + "/check_netapp_volume". To use the single binary, change the command array to call check_netapp with the object (and, where applicable, the subcommand) as separate arguments:
object CheckCommand "check_netapp_volume_usage" {
- command = [ PluginContribDir + "/check_netapp_volume", "usage" ]
+ command = [ PluginContribDir + "/check_netapp", "volume", "usage" ]
arguments = {
...
The arguments block and everything else stays the same.
No thresholds, flags, or check logic change — this is purely a packaging decision, and it’s entirely optional.
Where to find it
The new release is available for download at releases.monitoring-plugins.pro.
Comments