Installation

Installation Steps

  1. Prerequisites: Make sure the following are in place before you start:

    • A valid contract number for Check NetApp-REST
    • gpg (GnuPG) installed on the target system (optional, required for signature verification)
  2. Download the archive and its detached signature from releases.monitoring-plugins.pro. Your contract number is required to log in.

    Download both files for your target version:

    check-netapp-rest-<version>.tar.gz
    check-netapp-rest-<version>.tar.gz.asc
    
  3. (Optional) Verify the signature of the downloaded archive before installing. Full details and the public key fingerprint are in Release Archive Verification.

    Quick reference:

    curl -O https://docs.monitoring-plugins.pro/release-signing-key.asc
    gpg --import release-signing-key.asc
    gpg --verify check-netapp-rest-<version>.tar.gz.asc check-netapp-rest-<version>.tar.gz
    
  4. Create the directory /usr/local/monitoring-plugins.pro/netapp-rest/etc (if it does not already exist) and untar the downloaded archive to its parent.

    mkdir -p /usr/local/monitoring-plugins.pro/netapp-rest/etc
    tar -xzf check-netapp-rest-1.4.0.tar.gz --directory /usr/local/monitoring-plugins.pro/netapp-rest/
    
    Explanation of the commands ...
  5. Copy the license file to its default directory

    cp <your-CNR>_check_netapp_pro.dat /usr/local/monitoring-plugins.pro/netapp-rest/etc
    

    The example-configuration directory contains a license.cfg that will monitor the above directory for expiring licenses. More information about the license file and how to check for expiration can be found in the chapter License File.

  6. Create a storedir

    mkdir -p /usr/local/monitoring-plugins.pro/netapp-rest/var/store
    

    The above typescript creates the storedir at its default location. If you prefer it somewhere else you can either symlink the default-storedir to an other place or use the --storedir parameter.

    For customers who also use the Perl checks (Check NetApp-ZAPI): The checks from Check NetApp-REST have no explicit getter anymore but still use an auto-getter function to cache results locally. Therefore we still need a storedir.

  7. Change the owner of the files to the monitoring-daemons user. (In the example below, change the username from nagios to e.g. icinga or whatever your daemon runs with.)

    cd /usr/local/monitoring-plugins.pro
    chown -R nagios netapp-rest/
    
  8. Copy and adapt the example configuration. At least the hosts.cfg will need your attention (tell it about the host-names which should get monitored)

    cd /usr/local/monitoring-plugins.pro/netapp-rest/etc/
    cp ../etc.example/* .
    vi hosts.cfg
    ...
    
  9. Let the monitoring system know about the location of the configuration files. E.g. on Nagios or Icinga add the following line to the main configuration file (nagios.cfg, icinga.cfg, …)

    cfg_dir=/usr/local/monitoring-plugins.pro/netapp-rest/etc
    
  10. Create a monitoring role and user on your NetApp-system as described in Filer Configuration. Write the credentials of this user into the default authfile (/usr/local/monitoring-plugins.pro/netapp-rest/etc/netapp_credentials). The minimum authfile is:

    [default]
    user = monitoring_user_name
    pass = monitoring_user_password
    

    The keys are user and pass. The keys username and password (known from Check NetApp-ZAPI) are not read.

  11. Test one check on the command line before you reload the monitoring system. Run it as the user of the monitoring daemon (here nagios), so that missing permissions on the storedir or the license show up now:

    sudo -u nagios /usr/local/monitoring-plugins.pro/netapp-rest/bin/check_netapp_health --host=<cluster-mgmt-lif>
    echo $?
    

    A working installation returns something like:

    NETAPP HEALTH OK - 7 (sub)systems checked
    system.health: ok
    subsystem.switch_health: ok
    subsystem.cifs_ndo: ok
    subsystem.metrocluster: ok
    subsystem.metrocluster_node: ok
    subsystem.fhm_switch: ok
    subsystem.fhm_bridge: ok
    0
    

    The number and names of the subsystems depend on your system. CRITICAL or WARNING (exit code 2 or 1) means the installation works and the check found a problem on the NetApp. Exit code 3 (UNKNOWN) with one of the messages listed under Troubleshooting means the installation needs attention.

  12. Reload the configuration of the monitoring system. You should see the first results after the next check interval.

Troubleshooting

The checks report setup problems with exit code 3 (UNKNOWN) and a single line of text. The messages below are taken from the checks; <…> stands for your values.

Timeout

plugin timed out (timeout: <n>s)

The NetApp system did not answer within --timeout (default 10 seconds). Check that --host is the cluster management LIF and that a firewall allows HTTPS (port 443) from the monitoring server to it.

Host name not resolvable

could not send request with http client: Get "https://<host>/api/…": dial tcp: lookup <host>: no such host

The host name given with --host cannot be resolved. Use the IP address or fix the DNS entry.

Authfile missing

could not load auth file: open <authfile>: no such file or directory

The authfile does not exist. Create it (see the step above) or name it with --authfile.

No user in the authfile

could not find user for entry '<entry>' in file '<authfile>'

The authfile has no user key in the section for this host or in [default]. Most often the file still uses username/password; rename them to user/pass.

License file missing

No license-file (*.dat) found in '<license-dir>'. Please copy the license-file into the directory specified by --license-dir.

Copy the license file into /usr/local/monitoring-plugins.pro/netapp-rest/etc or name its directory with --license-dir.

Storedir not writable

failed to acquire API lock: mkdir <storedir>/<host>: permission denied

The user of the monitoring daemon cannot write to the storedir. Change the owner as described in the installation steps above.

Additional Notes

Compatibility with ZAPI Checks

The syntax of Check NetApp-REST is quite similar to the former get_netapp_cm.pl/check_netapp_pro.pl (now part of Check NetApp-ZAPI) with these exceptions:

  • --authfile|-f expects the new ini-format. The older text-format is not supported any more. The minimum authfile is now:

    [default]
    user = monitoring_user_name
    pass = monitoring_user_password
    
  • --port has been removed.

  • All underscores in the parameters have been replaced by dashes (e.g. --max_age is now written --max-age).

Using the authfile from the ZAPI Checks

Of course you can use the eventually already existing authfile from Check NetApp-ZAPI for Check NetApp-REST as well (if it is in the ini-format). Just symlink it into the above mentioned default-location or explicitly name it with the --authfile parameter. You can then administrate all NetApp hosts in one file for both of our monitoring products.

For customers migrating from Check NetApp-ZAPI: If you have used the option-alias username instead of user in the authfile, please change it to user now. This option can be read by both products. The same goes for password, which should be changed to pass.