Monitoring Configuration

Collector Checks vs. Stand-Alone Plugins

The plugin-suite Check NetAppPRO 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.

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

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_cm.pl volume -H filer

# this check compares the collected data against the thresholds
check_netapp_pro.pl 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 elaborate 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.

# cdot-Collectors
./run.sh get_netapp_cm.pl -o volume -H <filer91>  # collect volume data from cdot filer
./run.sh get_netapp_perfdata.pl -o volume -H <filer91>  # collect volume perf-data from cdot filer

# 7-Mode collectors
./run.sh get_netapp_7m.pl -o volume -H <filer>  # collect volume-data from a 7-Mode filer
./run.sh get_netapp_perfdata.pl -o 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_pro.pl Usage -H <filer> -o volume  # check volumes (both cdot and 7-Mode)

# some direct checks (not depending on collected data)
./run.sh check_netapp_mc_config.pl -H <filer>  # check a metro-cluster for its configuration
./run.sh check_netapp_health.pl -H <filer>  # check the global health status

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.

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 received from your distributor. They may act as template for writing your own cfg-files. The cfg-examples contain a configuration for each check arranged 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 can access these check or plugin specific help pages using the --help option on the commandline.