Monitoring Configuration

Collector Checks vs. Stand-Alone Plugins

The plugin-suite check_netapp_pro provides two different types of checks:

  • Collector-checks getting their data from a local store-file written by a collector (also known as getter due to their file-name get_netapp).
  • Standalone checks contact the filer directly. Among them are some legacy checks for 7-mode filers (check_netapp7_*.pl).

Knowing this we can now explain the configuration of each type of check.

Collector-Checks Explained

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 get_netapp.

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.

→ Check-Getter-Dependencies Matrix

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 etc/ dir.

Example

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 Explained

Standalone checks do not require any collector. They are configured like a traditional Nagios-plugin. You get their usage by running --help. (Some of them also provide a more elaborated man-page if called with --man.)

Examples

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

Authentication and Credentials-File

The most simple form of passing the credentials (username and password) to the NetApp-system is by using the two command-line switches --user|-u and --pass|-p.

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 default-section.

The default auth-file location is provided in the arguments help (as of writing of this document /usr/local/check_netapp_pro/etc/netapp_credentials). 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 the --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.

Setting the Mode (cluster-mode, 7-mode)

Also the --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 --mode defaults to cm anyway.

Writing cfg-Files

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 option --help in the commandline.

Also you may refer to the online-documentation at netapp-monitoring.info/en/matrix_check_netapp_pro.html.