repo reinit

.gitignore

@@ -0,0 +1,6 @@
+*.pyc
+*.pyo
+.svn
+*.egg-info
+build
+dist

MANIFEST.in

@@ -0,0 +1,8 @@
+# This graft causes all files located under the ZenPacks/ subdirectory to be
+# included in the built ZenPack .egg. Files located in the top-level directory
+# of the ZenPack will not be explicitly included.
+#
+# You can read more about the format and available options available in this
+# MANIFEST.in file at the following URL.
+# http://docs.python.org/distutils/sourcedist.html
+graft ZenPacks

README.md

@@ -0,0 +1,156 @@
+# NetApp 7-Mode ZenPack
+
+The ZenPack provides monitoring for NetApp data storage devices running ONTAP 7-Mode. Data is collected through ZAPI and ZAPI uses XML and HTTP to communicate with NetApp. NetApp Manageability SDK (NMSDK) provides wrapper around ZAPI in Python. This ZenPack is using these wrapper libraries. I hope I managed to get non-blocking code while waiting for the responses from the NetApp. Python Collector and deferreds are used through code, I hope I did that in a right way.
+
+<a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-01.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-01.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-02.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-02.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-03.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-03.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-04.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-04.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-05.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-05.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-06.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-06.png" width="200px" height="200px" /></a><a target="_blank" href="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-07.png"><img src="https://raw.githubusercontent.com/htolic/ZenPacks.CS.NetApp.SevenMode/master/screenshots/ss-07.png" width="200px" height="200px" /></a>
+
+## Releases
+
+Version 1.0.0 - [Download](https://github.com/htolic/ZenPacks.CS.NetApp.SevenMode/releases/download/v1.0.0/ZenPacks.CS.NetApp.SevenMode-1.0.0-py2.7.egg)
+
+- Released: 2019-02-26
+- Requires [PythonCollector ZenPack](https://www.zenoss.com/product/zenpacks/pythoncollector) (>=1.10.1)
+- Compatible with Zenoss 4.2.5, Zenoss 6.2.1
+
+## Table of contents
+
+- [NetApp 7-Mode ZenPack](#netapp-7-mode-zenpack)
+  - [Releases](#releases)
+  - [Table of contents](#table-of-contents)
+  - [Features](#features)
+    - [Device: NetApp 7-Mode](#device-netapp-7-mode)
+    - [Component: Aggregates](#component-aggregates)
+    - [Component: Disks](#component-disks)
+    - [Component: Plexes](#component-plexes)
+    - [Component: RAID Groups](#component-raid-groups)
+    - [Component: Spare Disks](#component-spare-disks)
+    - [Component: Volumes](#component-volumes)
+  - [Usage](#usage)
+  - [Changelog](#changelog)
+
+## Features
+
+### Device: NetApp 7-Mode
+
+- Creates Device Class /Storage/NetApp/7Mode
+- Creates Event Class /Events/Storage/NetApp
+- Adds Modeler Plugin CS.ZAPI.NetApp7Mode
+  - Models information about device (serial_no, system_id, system_model, ontap_version)
+  - Models information about components:
+    - Aggregates (name, state, mount_state, raid_size, raid_status, disk_count, volume_count, plex_count, total_bytes)
+    - Disks (name, disk_uid, node, raid_state, raid_type, bay, byte_per_sector, disk_type, rpm, model, serialnr, firmware, poweron_hours, grown_defect_list_count, total_bytes)
+    - Plexes (name, state)
+    - RAID Groups (name)
+    - Spare Disks (name, node, disk_uid, raid_state, raid_type, bay, byte_per_sector, disk_type, rpm, model, serialnr, firmware, poweron_hours, grown_defect_list_count, total_bytes)
+    - Volumes (name, type, block_type, volume_state, mirror_status, inconsistent, unrecoverable, invalid, total_bytes)
+- Configuration Properties set on class /Storage/NetApp/7Mode
+  - zDeviceTemplates - value: NetApp7Mode_Device
+  - zPythonClass - value: ZenPacks.CS.NetApp.SevenMode.NetAppDevice
+  - zIcon - value: /zport/dmd/++resource++netapp/img/icon.png
+  - zSnmpMonitorIgnore - value: true
+- New Configuration Properties
+  - zNetAppFiler - default: [empty] (if empty, device.manageIp is used)
+  - zNetAppTransport - default: HTTPS
+  - zNetAppUser - default: root
+  - zNetAppPassword - default: [empty]
+- Monitoring Template
+  - Python datasource_plugin: NetAppDeviceDSP
+  - Data Points collected and Graph Definitions:
+    - Graph "CPU Utilization" - cpu_pct
+    - Graph "Protocol Ops" - nfs_ops, cifs_ops, http_ops, fcp_ops, iscsi_ops
+    - Graph "Read-Write Ops" - read_ops, write_ops, total_ops
+    - Graph "Latency" - sys_read_latency, sys_write_latency, sys_avg_latency
+    - Graph "Network data" - net_data_recv, net_data_sent
+    - Graph "Disk data" - disk_data_read, disk_data_written
+    - Not displayed on any graph - sysUpTime
+  - Thresholds:
+    - high CPU utilization
+      - Type: MinMaxThreshold
+      - Condition: cpu_pct > 50
+      - Triggers: Critical severity event in Event Class /Storage/NetApp
+
+### Component: Aggregates
+
+- Monitoring Template
+  - Python datasource_plugin: NetAppAggregateDSP
+  - Data Points collected and Graph Definitions:
+    - Graph "Space Usage" - size_used, size_available
+    - Graph "Percent Used" - percentage_used
+    - Graph "Read-Write Data" - user_reads, user_writes
+  - Thresholds:
+    - high aggregate usage
+      - Type: MinMaxThreshold
+      - Condition: percentage_used > 90
+      - Triggers: Critical severity event in Event Class /Storage/NetApp
+
+### Component: Disks
+
+- Monitoring Template
+  - Python datasource_plugin: NetAppDiskDSP
+  - Data Points collected and Graph Definitions:
+    - Graph "Space Usage" - size_used, size_available
+    - Graph "Percent Used" - percentage_used
+    - Graph "Read-Write Data" - user_reads, user_writes
+  - Thresholds:
+    - high disk usage
+      - Type: MinMaxThreshold
+      - Condition: percentage_used > 98
+      - Triggers: Critical severity event in Event Class /Storage/NetApp
+
+### Component: Plexes
+
+- No Monitoring Template available as no usable data is provided through ZAPI
+- Only "Plex State" collected by modelling the device
+
+### Component: RAID Groups
+
+- No Monitoring Template available as no usable data is provided through ZAPI
+
+### Component: Spare Disks
+
+- Monitoring Template
+  - Python datasource_plugin: NetAppSpareDiskDSP
+  - Data Points collected and Graph Definitions:
+    - Graph "Space Usage" - size_used, size_available
+    - Graph "Percent Used" - percentage_used
+  - Thresholds:
+    - high disk usage
+      - Type: MinMaxThreshold
+      - Condition: percentage_used > 98
+      - Triggers: Critical severity event in Event Class /Storage/NetApp
+
+### Component: Volumes
+
+- Monitoring Template
+  - Python datasource_plugin: NetAppVolumeDSP
+  - Data Points collected and Graph Definitions:
+    - Graph "Space Usage" - size_used, size_available
+    - Graph "Percent Used" - percentage_used
+    - Graph "Latency" - read_latency, write_latency, avg_latency
+    - Graph "Read-Write Data" - read_data, write_data
+  - Thresholds:
+    - high volume usage
+      - Type: MinMaxThreshold
+      - Condition: percentage_used > 70
+      - Triggers: Critical severity event in Event Class /Storage/NetApp
+
+## Usage
+
+First make sure you are using supported Zenoss version and have ZenPack dependencies on right version installed. Then proceed to download and install this ZenPack using a standard procedure for your version of Zenoss.
+
+This ZenPack monitors NetApp storage devices running only ONTAP 7-Mode. It is tested against NetApp Release 8.2.3 7-Mode. NetApp C-Mode is not supported with this ZenPack and it will not work.
+
+After installation the device class /Storage/NetApp/7Mode is created. Go ahead and modify Configuration Properties for this device class. Look for properties that have name starting with zNetApp.
+
+- zNetAppFiler: This is IP address where ZAPI listens for API requests. Leave this empty if IP address you enter when adding device is the same as IP address of NetApp Controller management interface (this is where ZAPI usually listens). If you ever need to change this property, change it per device of course.
+- zNetAppTransport: This will either be HTTP (if ZAPI listens on port TCP/80) or HTTPS (if ZAPI listens on port TCP/443). Check your network configuration and firewall rules so Zenoss can reach Filer on either HTTP or HTTPS.
+- zNetAppUser: This defaults to root. If you have user prepared especially for Zenoss monitoring then use that user. The user must have privilege to make queries to ZAPI.
+- zNetAppPassword: Enter a password related to user that you use in zNetAppUser property.
+
+Go ahead, add your devices to /Storage/NetApp/7Mode and wait for modelling to finish. If everything goes well, you should see components showing up on device details page. In a couple of minutes the graph data should start populating too.
+
+## Changelog
+
+Version 1.0.0
+
+- Initial release

README.txt

@@ -0,0 +1,164 @@
+# ZenPack Template
+This README describes the structure of the ZenPack template that gets
+automatically created by Zenoss when you add a ZenPack through the web
+interface.
+
+## Files
+At the top-level a ZenPack must have a setup.py. Almost always a MANIFEST.in
+file should exist, and in cases where external dependencies must be built for
+inclusion in the ZenPack, a GNUmakefile. Examples of these files with inline
+comments are included in this template.
+
+Also included in the ZenPackTemplate is a configure.zcml. As more of Zenoss'
+extensibility moves to using ZCA (Zope Component Architecture) this file
+becomes crucial to hooking into various aspects of Zenoss.
+
+## Files and Subdirectories
+The following sections describe the purpose and use for each of the default
+subdirectories. Note that if the described functionality is not of use in your
+ZenPack it is safe to remove any of the default directories.
+
+### src/
+The src/ top-level directory in ZenPacks is the conventional place to add
+third-party dependencies to your ZenPack. It should only be used as a staging
+area to do any build work necessary for the dependency.
+
+See GNUmakefile (or GNUmakefile.example) for examples of how to have
+your third-party dependencies automatically compiled and installed at the right
+time and into the right location.
+
+### ZenPacks/NAMESPACE/PACKNAME/
+The following sections describe the directories contained within the
+namespaced ZenPacks/NAMESPACE/PACKNAME/ subdirectories.
+
+#### bin/
+Any general tools delivered by your ZenPack that would be used by the Zenoss
+administrator at the command line should go into this directory by convention.
+When the ZenPack is installed all files in this directory will be made
+executable.
+
+#### browser/
+The browser subdirectory should contain all code and configuration that's
+specific to the Zenoss web interface. The provided configure.zcml will
+automatically load the example browser/configure.zcml and register the
+browser/resources/ subdirectory to serve static web content.
+
+#### daemons/
+All files in the daemons/ subdirectory get special handling. Upon installing
+the ZenPack, the following actions will occur.
+
+    1. The file will be made executable (chmod 0755)
+    2. A symlink to the file will be created in $ZENHOME/bin/
+    3. An configuration file will be generated at $ZENHOME/etc/DAEMON_NAME.conf
+
+Assuming that you don't have a $ZENHOME/etc/DAEMONS_TXT_ONLY file this daemon
+will also become part of the normal zenoss start and stop processes.
+
+You can find an example daemon control script in daemons/zenexample. For most
+purposes this file can be renamed to the name of the daemon you want to create
+and modified to change the DAEMON_NAME. No other modifications are typically
+needed. Note that this example control script does expect to launch the real
+daemon code which should be located at ../DAEMON_NAME.py.
+
+#### datasources/
+Any new datasource types you want to add must be added as classes into the
+datasources/ subdirectory. When Zenoss is building the list of available
+datasources it will scan the datasources/ subdirectory for all installed
+ZenPacks.
+
+An example datasource at datasources/ExampleDataSource.py.example.
+
+#### lib/
+The lib/ directory should be the installation target for any third-party
+libraries that are built by the GNUmakefile. It can also be used as the
+conventional location to drop Python-only libraries that don't require
+any compilation or special installation.
+
+#### libexec/
+Any scripts executed by COMMAND datasources in your ZenPack go in this
+directory by convention. When the ZenPack is installed all files in this
+directory will be made executable.
+
+#### migrate/
+ZenPacks can include migrate scripts that allow you to run custom code to
+handle any tasks that are needed to upgrade your ZenPack from one version to
+another. All .py files in this migrate/ subdirectory will be evaluated when the
+ZenPack is installed.
+
+You can find an example migrate script at migrate/ExampleMigration.py.
+
+#### modeler/
+Any modeler plugins distributed with your ZenPack must be located under the
+plugins/ subdirectory. The directory structure and filenames under plugins/
+map directly to the plugins' name in the user interface. For example, if you
+wanted to create a modeler plugin called "community.snmp.ExampleMap" you would
+create the following directory structure.
+
+It is recommended that the first portion of the namespace be a short lowercase
+form of your name, or organization's name. Alternatively you can choose to use
+"community" if you plan to publish the ZenPack and are open to outside
+contributions. Zenoss, Inc. will always use "zenoss." The second portion of the
+namespace can be the protocol that is used to collect the data. If you are not
+using a common protocol it is acceptable to skip the second portion of the
+namespace and have something like "community.MongoDB" instead.
+
+plugins/
+    __init__.py
+    community/
+        __init__.py
+        snmp/
+            __init__.py
+            ExampleMap.py
+
+Note that the __init__.py files must exist and should be empty files. Otherwise
+your modeler plugins won't be imported and usable within Zenoss.
+
+#### objects/
+All .xml files in this objects/ directory will be loaded into the object
+database when the ZenPack installs. All of the objects defined in the XML files
+will be automatically associated with the ZenPack.
+
+When you export the ZenPack from the user interface all objects associated with
+the ZenPack will be exported into a file called "objects.xml" specifically. For
+this reason it is recommended to let Zenoss manage the objects.xml file and to
+never manually create or modify any .xml files in this directory unless you
+know what you're doing.
+
+When a ZenPack is removed, any objects associated with the ZenPack will be
+recursively removed from Zenoss. For example, if you associated the /Server
+device class with your ZenPack and removed the ZenPack, the /Server device
+class, and all devices within it would also be deleted.
+
+When a ZenPack is upgraded, or re-installed on top of itself, all objects in
+the XML files are overlaid on the existing object database. This results in a
+merge of the existing objects and what are defined in the XML files with the
+XML file properties and relationships winning any conflicts.
+
+#### reports/
+Custom reports will be loaded from this directory when the ZenPack is
+installed. Subdirectories (with the exception of plugins/) will be mapped
+directly to the report folders in the web interface. So if you add a .rpt file
+into a subdirectory named "Performance Reports" you will find your report in
+the Performance Reports folder in the web interface after installing the
+ZenPack.
+
+The plugins/ subdirectory should include any Python plugins your custom reports
+call. So if your .rpt file contains a line such as the following..
+
+objects python:here.ReportServer.plugin('myplugin', tableState);
+
+There should be a corresponding myplugin.py file in the plugins/ subdirectory.
+
+You can find an example report at Example Reports/Example Report.rpt.example
+that uses a plugin which can be found at plugins/example_plugin.py.
+
+#### services/
+ZenHub services will be loaded from the services/ directory. These services
+run inside the zenhub daemon and are responsible from all interaction with
+collector daemons.
+
+You can find an example service at services/ExampleConfigService.py.
+
+#### tests/
+All unit tests for your ZenPack should live in this directory. You can find an
+example test suite at tests/testExample.py.