One of our customers asked if we could develop a plugin that determines the last access date/creation date/modification dates of the NFS shares. After a certain age of these shares, an alarm should be triggered. They need this information to identify the obsolete shares of users and clean up the unused space in the NetApp storage.
Availability The required monitoring plugin check_netapp_nfs cold-data has no fixed release date yet. Customers also interested in this new functionality are asked to send us a short e-mail to express their interest and optionally request a testing-version of the plugin.
Those who have been reading this blog for a while may have noticed that we have “moved”. In addition to the design the domain is now different, the new structure allows us to write about the new monitoring plugins as well as our traditional storage plugins.
How do we ensure that there is not a single “broken link” in over 300 articles? We had feared that the transfer of the articles from the old blog could not be done completely automatically.
We are pleased to announce the 1.1.0 release of our monitoring plugin check_site_simple.
The following is new in this version:
The links to images and other media are checked as well. This means that incorrectly embedded images or videos or those whose sources no longer exist are now recognized as well.
Links to external sources can be provided with their own grace period. The background for the introduction of this new option is that sometimes servers to which you want to link are unstable.
The v1.2.0 release of our Check NetApp-REST product contains a new monitoring plugin called check_netapp_volume usage. It provides the monitoring of:
the used space of each volume (in Bytes) the total used space of several volumes the average used space of several volumes the min/max of used space of several volumes A typical output would look like:
$ check_netapp_volume usage -H filer -w 30GiB -c 50GiB NETAPP VOLUME USAGE OK - 5 volumes checked vserv_b.
The v1.1.0 release of our Check E-Series product brings also a new monitoring plugin called check_eseries_nic. This provides monitoring of:
the link-status (up/down) the current-speed (1Gib/s, 10GiB/s, …) setup-error (true/false) A typical output would for the link-status check look like:
$ ./check_eseries_nic link-status -H 10.1.1.11 --system-id=1 NETAPP ESERIES NIC CRITICAL - 4 nics checked, 3 CRITICAL wan1.280107001000000000000: down (CRITICAL), slot 1, label P2 wan0.280007001000000000000: up, slot 0, label P1.
We have released a new monitoring plugin called check_eseries_pool. The first version has exactly one subcommand called free-space. This monitors the free space still available for thin volumes in the disk pool.
It is particularly useful when you start taking snapshots or mirroring to another system. In such cases, you will monitor the FreePoolSpace to track the changes until they are mirrored to the other system or until the snapshot is deleted.
Less can be more Some time ago, we received an enquiry in which a customer illustrated a general problem using the LUN check as follows:
If I run ./check_netapp_pro.pl LunState -H fas --alarm_limit 1
This will show you all the LUNs on the Cluster, both online and offline. We have systems that contain over 200 LUNs, so Nagios shows a very long list of LUNs, which is confusing for some users.
The plugin check_netapp_shelfenv does not work in Ontap 9.8 After much back and forth, we have now received confirmation that in Ontap 9.8 the endpoint /api/private/cli/storage/shelf for the RESTful API is missing or not working.
On the command line it looks like this:
curl -X GET -u nagios:**** -k https://some.filer.com/api/private/cli/storage/shelf { "error": { "message": "entry doesn't exist", "code": "4", "target": "shelf" } } This is of course unfortunate, because it means that our plugin check_netapp_shelfenv can no longer function.
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.