The plugin-suite Check NetAppPRO provides two different types of checks:
Knowing this we can now explain the configuration of each type of check.
Every collector-check needs at least one local store-file regularly
updated by a collector (aka getter). The collectors are also
implemented as Nagios service-checks. Since v6.x we provide one universal collector named
This universal getter can be configured with different objects like volume, aggregate, lun, processor, etc. If you enter a wrong object-name the getter will list the available object-names. Nevertheless it could be tricky, to exactly find the required objects. Therefore we are providing a table documenting clearly which getter-objects must have been collected so that a check can run.
Although the essential information is correct in the above linked table it is still using the older Perl syntax from the previous version of the plugins. We are already working on an updated table. In the meanwhile please consider also the example-configurations in the tarballs
To successfully monitor the usage of volumes on a filer both a getter for the volume-object and a check must run:
# this command collects the data get_netapp volume -H filer # this check compares the collected data against the thresholds check_netapp Usage -H filer -o volume -w 80 -c 95
Standalone checks do not require any collector. They are configured like
a traditional Nagios-plugin. You get their usage by running
(Some of them also provide a more elaborated man-page if called with
Example command-lines for getter, collector-checks and direct-checks. All of them are using the new universal getter/check syntax. The run.sh calls them from within the dependency free docker image.
Enlarging the width of your browser window will enhance the readability of the following examples.
# cdot-Collectors ./run.sh get_netapp volume -H <filer91> # collect volume data from cdot filer ./run.sh get_netapp performance volume -H <filer91> # collect volume perf-data from cdot filer ./run.sh get_netapp certificate -H <filer96> # collect certificate-information (restful API, ONTAP >=9.6 onyl) # 7-Mode collectors ./run.sh get_netapp volume -H <filer> --mode=7m # collect volume-data from a 7-Mode filer ./run.sh get_netapp performance volume -H <filer> --mode=7m # collect volume perf-data from a 7-Mode filer # Checks based on the stored data collected by the above getters ./run.sh check_netapp Usage -H <filer> -o volume # check volumes (both cdot and 7-Mode) ./run.sh check_netapp Certificate -H <filer96> # check certificate expiration # some direct checks (not depending on collected data) ./run.sh check_netapp MC-Config -H <filer> # check a metro-cluster for its configuration ./run.sh check_netapp Health -H <filer> # check the global health status ./run.sh check_netapp SnapCenter -H <filer> # check the SnapCenter database for failed jobs
The most simple form of passing the credentials (username and password)
to the NetApp-system is by using the two command-line switches
It is also possible to write the credentials into a file and do away
with constantly passing the information on the commandline. The full
path for this file is passed to the script using the argument
--authfile|-f. The format of this file is simple:
[default] username=monitoring password=test12345 [filer01] username=root password=myPasswd [filer02] username=admin password=myOtherPasswd
The section names are the host-names as given to the getters and
direct-checks with the
--host parameter. All hosts not explicitly
listed in a section are contacted with the credentials from the
The default auth-file location is provided in the arguments help (as
of writing of this document
Provided that this file is in its default-location you can omit the
--authfile|-f argument in all cases too.
The authfile (
--authfile) is the recommended form of passing the credentials.
It gives you more flexibility and helps to keep the commandline short. Also
--storedir has a reasonable default which may avoid the requirement to
explicitly set it.
The authfile has a new default location since v6.0.0. If you are using cfg-files from an older version which call a Perl-script directly, it will not find the authfile in the new default location any more.
--mode parameter can be set on a by-host base in
the credentials file.
[filer07] mode=7m username=root password=myPasswd
Setting the mode explicitly for cdot-filers is of no use, since
defaults to cm anyway.
A good start are the example cfg files you got together with the docker-image from your distributor. They may act as template for writing your own cfg-files. The cfg-examples contain a configuration for each check ordered by bundle (Base Bundle, Advanced Bundle, Performance Bundle, ...). For experimental features and hardware-parts, which are not available on every filer (flash-cache) extra cfg-files are provided, which can be referenced on demand.
Of course not all possible options are mentioned in these examples. Each getter or check has its own help- and manual-page explaining all
available options and showing examples. You get this specific help with the
--help in the commandline.
Also you may refer to the online-documentation at netapp-monitoring.info/en/matrix_check_netapp_pro.html.