How to integrate the EMS-Log into an existing System-Monitoring solution In this article ONTAP REST APIs: Automate Notification of High-Severity Events Mahalakshmi describes how to use messages to get notified about system events, depending on their type and severity. It’s a really flexible and comprehensive way to monitor NetApps ONTAP.
What if you already have a system-monitoring solution like Nagios, Icinga, op5 Monitor or Shinken in place? In that case the destinations (the recipients of the notifications) are already defined in the monitoring system.
The family of Check NetApp REST monitoring plugins has grown. With the check_netapp_disk container-type plugin the storage admin has a constant eye on disks that have been moved into unwanted containers.
Let’s look at an example:
.$ check_netapp_disk container-type -H sim96 NETAPP DISK CONTAINER TYPE OK - 28 disks checked sim96cluster-01.NET-1.28: spare sim96cluster-01.NET-1.27: spare sim96cluster-01.NET-1.26: aggregate sim96cluster-01.NET-1.25: aggregate sim96cluster-01.NET-1.24: aggregate sim96cluster-01.NET-1.23: aggregate sim96cluster-01.NET-1.22: aggregate sim96cluster-01.NET-1.21: aggregate sim96cluster-01.NET-1.20: aggregate sim96cluster-01.NET-1.19: spare sim96cluster-01.
The new VolumeAge check for check_netapp_pro warns about overly old or exceptionally young volumes, where the age is calculated as the difference between the volume creation-time and now.
Thresholds (--warning, --critical) may be set in days (d) or week (w). Various arguments can be used to narrow down the search in more detail, see the online docs. for other options. A particularly useful feature to check for young volumes is to invert the comparison-logic with --comparison=lt (less-than).
Updating to a New Version | Monitoring NetApp - Jan 4, 2015
[…] longer needed remain. This rarely happens and causes no i. E.g.: currently this is the case with DiskFailed that is being replaced by Disk. If you want to avoid this, you have to delete all existing checks and corresponding files first. […]
The new **Disk **check monitors the disks of a NetApp Filer. Depending on the settings, the check sends an error message when offline or failed disks are found.
An example using a 7-Mode Filer: $ **./check_netapp_pro.pl Disk -H sim812 ‑‑what=failed** NETAPP_PRO DISK CRITICAL - 14 disks checked, 1 critical and 0 warning. sim812 v5.16: not failed sim812 v5.17: not failed sim812 v5.18: not failed sim812 v5.19: not failed sim812 v5.21: not failed sim812 v5.
Turning Off Performance Data Output | Monitoring NetApp - Jan 3, 2015
[…] a check for each volume that outputs performance data and the corresponding graph. Thanks to the collector architecture no additional requests have to be sent to the […]
#### [Collectors and Distributed Monitoring | Monitoring NetApp](https://blog.monitoring-plugins.pro/posts/collectors-and-distributed-monitoring/ "") - Jan 4, 2015 […] Collectors have some great advantages: the monitored device is put under less computational load and a greater flexibility for the configuration of service checks.
Our present monitoring-plugin for NetApp FAS devices, named check_netapp_pro is based on the so-called collector architecture. This allows us to monitor even the most complex storage-systems like Fabric Metro Clusters.
The collector architecture works as follows:
Collectors are distinct scripts that collect all the data that the checks require and saves it in a Store on the Nagios Server. The checks have access to the Store and no longer contact the NetApp devices themselves.
How can I find Volumes without any Snapshots? How can you find out which Volumes on the Filer don’t have any Snapshots? The check Snapshots,which is included in our Suite check_netapp_pro, provides a relatively easy way of achieving this. The following example demonstrates how it can be used:
$ check\_netapp\_pro Snapshots ... --metric=number -w 1 -c 1 --comparison=lt With the above command, every Volume that has less than 1 Snapshot will trigger the Monitoring System (e.
Version 3.0.7 of our Monitoring Plugins for NetApp (check_netapp_pro) will be available soon and will include a number of new features that have been implemented based on feedback we received from our customers:
New Check PerfSys: Not entirely new, but taken over from the stable version 2.x to version 3.x. In this new release, system-wide performance counters such as transfer-rate or _operations per second _ can also be checked on cluster mode Filers.
So you would like to monitor the latency of your NetApp device? Then you must be careful: in addition to the “latency” that usually refers to the “per volume latency”, the latency of a LUN can also be measured, which is not to be confused with the latency of the volumes on which the LUN is based. Therefore we have developed a plugin, that correctly detects the latency of a LUN: http://netapp-monitoring.