This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.
Monitoring for NetApp storages.
This ZenPack is included with commercial versions of Zenoss and enterprise support for this ZenPack is provided to Zenoss customers with an active subscription.
NetAppMonitor provides additional modeling and monitoring for NetApp devices. NFS, CIFS and HTTP operations per second are collected, as well as file system and snapshot utilization information. Hardware model and operating system revision asset information is modeled.
The NetApp ZenPack uses reports provided by the StorageBase ZenPack.
The features added by this ZenPack can be summarized as follows. They are each detailed further below.
Verify that you have the following prerequisites before installing and using this ZenPack.
Installing or updating NetApp ZenPack may require the StorageBase ZenPack to be updated too. Each of these will require Zenoss to update the index and may take up to several hours depending on the number of objects related to these ZenPacks.
Application:ontapi, Authentication:password, Role:readonly
Place a device in the /Storage/NetApp/7-Mode or /Storage/NetApp/C-Mode Device classes to enable NetApp ZAPI based monitoring of the NetApp Appliance. Placing a device in the /Storage/NetApp/SNMP Device class will enable legacy SNMP monitoring of the NetApp Appliance.
7-Mode and C-Mode Zapi monitoring will model:
Note: C-Mode Volumes which are MetroCluster mirrors of volumes resided on another device will not have metrics.Such volumes marked with "Mirror" property.
Note: Volumes "Data" or "Data Sector" for _Size_, _Used_, _Available_ means sector of Volume which is used exclusively for
user data, snapshot spill and doesn't include Snapshot reserve size, whereas "Total" applies to whole Volume size, including Snapshot reserve.
NetApp uses SSH to model NFS clients of file systems. It uses SNMP to model:
Optionally, configure SNMP for 7-Mode NetApp devices and disable zSnmpMonitorIgnore property to monitor statuses for Interface components and monitor trunked interfaces through SNMP.
Events (all versions)
options snmp.enabled on
snmp traphost add
snmp init 1
For more information see NetApp Support and Commands for managing SNMP.
Replace yourzenossserver with the IP or DNS name of your Zenoss server.
SNMP traps should be enabled for LUN devices to receive events if a LUN goes offline.
Since version 4.0.0 NetAppMonitor ZenPack provides support for monitoring events from OnCommand Unified Manager versions 9.4-9.5. To add monitoring of OnCommand Unified Manager events, it is required to add datasource of 'NetAppMonitor OCUM' type on a device level, and to fill related zProperties like zNetAppOCUMHost, zNetAppOCUMUser, zNetAppOCUMPassword. Events of OnCommand Unified Manager could be filtered by configuring zNetAppOCUMEventFilter. This property can be configured to filter events by:
Note: To monitor events from OnCommand Unified Manager it is required to have access to the REST API.
Perform the following steps to set a custom threshold for lag time metric on SnapMirror component.
Pay attention, that you should type the Maximum Value in seconds, so if you want to set, for example, 5 minutes, you should type 300 (60 seconds * 5)
Most components are collecting performance metrics from the perf subsection of the ZAPI calls. When modeling we collect the base uuid and store the information as a set of component XPath entries.
In most cases, we need to just add a new datapoint to the existing datasource, and then add the appropriate XPath fragment to retrieve the appropriate data.
Be cautious when enabling new metrics as large numbers of components can significantly increase the number of monitored datapoints being collected.
If zenpack ZenPacks.zenoss.LinuxMonitor is installed and Linux devices under /Server/SSH/Linux use known NetApp devices as NFS servers, then Storage Device property on Linux Filesystem component will be transformed into link to the appropriate NetApp Filesystem
When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact capability for NetApp devices. The following service impact relationships are automatically added. These will be included in any services that contain one or more of the explicitly mentioned entities.
Service Impact Relationships
This ZenPack provides additional support for Zenoss Analytics. Perform the following steps to install extra reporting resources into Zenoss Analytics after installing the ZenPack.
You can now navigate back to the NetAppMonitor ZenPack folder in the repository to see the following resources added by the bundle.
For Analytics 4.x domains can be used to create Ad Hoc views using the following steps:
For Analytics 5.x domains can be used to create Ad Hoc views using the following steps:
Please refer the Zenoss Service Dynamics documentation if you run into any of the following problems:
If you cannot find the answer in the documentation, then Resource Manager (Service Dynamics) users should contact Zenoss Customer Support. Core users can use the #zenoss IRC channel or the community.zenoss.org forums.
Recursion error on a large number of records - to eliminate this error the value of zNetAppNumRecordsPerRequest zProperty can be increased to process more records per one request.
Links for a component field of OnCommand Unified Manager related events are build based on a particular property on device level which is filled with IDs of all components existing on NetApp device. For this property to be filled correctly enable modeler plugins for related components and remodel device. Also, it is possible that links between OnCommand Unified Manager related events and components are missing because associated components do not exist on NetApp device in Zenoss.
ZenPack uses timestamps from the NetApp system during adding OnCommand Unified Manager related events. In case if an event is too old based on the event's configuration of the Resource Manager, it will not appear on the device. It is possible to modify this behaviour by changing the configuration of Event Aging Threshold (hours) and Don't Age This Severity and Above properties on Events tab on Advanced page.
The following collection daemons are required to collect NetApp data.
The current release is known to have the following limitations.
When upgrading from 3.6.x to a newer version, it is recommended to ensure that the 'zenpython' service is shut down prior to upgrading this zenpack, and only restart it once the upgrade is complete. This will eliminate the issue and speed up the upgrade process.
After upgrade to 4.x or newer version, when there are SNMP based NetApp devices placed under '/Storage/NetApp' - `AttributeError: 'NoneType' object has no attribute 'getRRDDataPoints'` flare could appear when clicking Component graph in UI. This happens because some component templates from the '/Storage/NetApp' were moved down into '/Storage/NetApp/SNMP' device class.Possible solutions:
Error events with a message `Unable to process COMMAND datasource(s) for device <device-name> -- skipping` may appear after upgrade to 4.1.0 or older version. They are not cleared automatically, so they may be acknowledged or closed manually. These events occurs only once during ZenPack upgrade installation and does not affect anything. Further upgrades (starting from 4.1.0 version) will not produce such events.
On Zenoss 5.3.3 some of the components may be displayed incorrectly. If this issue is encountered, restart zproxy service (by restarting) top-level "Zenoss.resmgr" application in Control Center. It is not necessary to restart the child services.
NetApp Monitor ZenPack assigns severity 5 to security.invalid.login events generated on NetApp devices. This can cause dedup collisions from different devices with this particular event. This is due to our event system considering these events to be duplicates by disregarding the event summary. The reason for this is they occur on the same device/component, and NetApp does not give us a way to determine if summaries are different due to some transient information (like 83%) or because they are two distinct issues. If we were to consider such events as non-duplicates, the result would be more events (84%, 85%, etc) and more open incidents. Additionally, such events cannot be cleared automatically.