Since 4.0.0 every over-all check has a feature, which we call “instance-name contains node-name". We have introduced this as an replacement for the sporadic available --node|--vserver parameter (not available any more). So since then each instance-name has the name of its node prefixed. This allows to use the --include|--exclude parameters to filter for all instances of a specific node.
E.g. if you have a new-node with a different hardware you may want to check only the ports of this new-node:
We are happy to announce the availability of the 4.0.2 release of check_netapp_pro. This version fixes a bug regarding the parameter --max_records introduced in 4.0.0. Please do not forget that 4.0.0 was a major release and we highly recommend all users to read this article, and then the installation documentation which is distributed with the product, before installing!
A bug has been reported against the latest check_netapp_pro release which involves the --max_records parameter being ignored leading to a timeout. This affects a subset of use-cases, for which we have no installations to ensure automatic test coverage, specifically 45000 instances.
> check_netapp_pro/get_netapp_snapshot.pl ‑‑timeout=300 ‑‑critical=180 ‑‑warning=120 --host=$host ... --max_records=1000 Data for object ‘vol_snapshot’ collected within 375.363s. Number of instances stored: 44221 | total_duration=375.363s;120;180;0; collect_duration= 362.467s ;;;0; store_duration=12.896s;;;0; total_instances=44221;;;0;
In the normal case this particular run might be expected to take about 40 seconds or so.
The latest check_netapp_pro release v4.0.0 was delivered with a missing file required_perl_modules.txt. If necessary, you can fetch the file manually using the following link: required_perl_modules.txt This file omission will be fixed in v4.0.2, due for release mid-November 2018 after which time it will be available from the Q-Portal. For more information on exactly what has changed and when, please check out the release history.
We are happy to announce the availability of the 4.0.1 release of check_netapp_pro. This version fixes a bug from 4.0.0. Please do not forget that 4.0.0 was a major release and we highly recommend to read this article before installing!
Unfortunately a bug slipped trough all of our test for the release v4.0.0 from 16th of October.
Scope The check UsageTrend does not work in that release, due to a failure in the getter for the volume and the aggregate-object. (The getters switch --stm is silently ignored.) All other checks not relying on the --stm switch are not affected.
Recommendation Customers who have already installed the 4.0.0 version should disable the UsageTrend checks.
NetApp Monitoring are pleased to announce check_netapp_pro release v4.0.0 on 16th of October. This is a major release, as reflected in the major number increment, which encapsulates a thorough refurbishment of the software suite. This release introduces several new options and at the same time deprecates several others, and thus dictates certain changes to the configuration. The upgrade is an opportunity to review the existing configs and to clean out the cruft.
NetApp MetroClusters have a new check for connections which assists with showing the results of connections for nodes. This check was introduced with the v9.4 DataONTAP release to check the connection of MetroCluster over IP partner nodes, and includes checks for the partner cluster and configuration settings, network endpoints, MTU sizes and subnets, and storage daemons. The check_netapp_takeover.pl script, which is an umbrella check handling several others from check_netapp_pro, has been flagged as having unexpected issues with handling this new MetroCluster connection check for some customers.
We are happy to be able to deliver the first testing release to customers who want to see how their requests have been implemented. Also any other customer of check_netapp_pro who would like to test if the upcoming major release 4.0 will (better) suite his needs is highly appreciated as a tester.
What’s new? Fundamental changes under the hood should make the getters more efficient and stable.
Dedicated getters for some objects have been precisely tailored.
The present version of the Snapshots-check already understood the filtering parameter --check_only=no_reserve|with_reserve. Based on a customer request we implemented now the ability to add an additional filter for selecting volumes with or without LUN. Example: $ ./check_netapp_pro Snapshots -H filer --check_only=with_lun As mentioned above this filter can be combined now with the already existing --check_only=no_reserve|with_reserve.``` $ ./check_netapp_pro Snapshots -H filer –check_only=with_lun –check_only=no_reserve
* do have a LUN * do not have a snapshot-reserve set.