ZenPack Taxonomy

ZenPacks can be used to override almost any functionality of the Zenoss platform, or to add any new features. This wide-open extensibility is much like Firefox’s add-on system and has the natural result of people building some surprising things. For this reason it can be difficult to answer the question, “What is a ZenPack?”

This document will outline the various ways ZenPacks can be classified to make it easier to find the ZenPack you need, describe a ZenPack that already exists, and to serve as an example for what is possible.

ZenPack Classifications

Every ZenPack will be classified using one or more of the elements listed under each classifier property. Some classifier properties have mutually exclusive elements, and some do not. This distinction will be made in the definition of each classifier property. For examples of how some existing representative ZenPacks are classified see Example ZenPack Classifications.


Functionality

Functionality classifies the high-level type of feature(s) provided. Specifically its type of interaction with the environment outside of the Zenoss platform. It is highly recommended that these categories be treated as mutually exclusive. While it is possible for a ZenPack to build a ZenPack that delivers functionality in more than one of the following categories, this can lead to less modularity and confusion about what a ZenPack does.

Monitoring

Monitoring is one or more of status, event and performance collection. The collection can be through active polling, passive receiving or both. A monitoring ZenPack provides functionality to perform this collection for a specific target technology.

Integration

Integration is defined as being any interaction with systems outside of Zenoss not deemed to be a Monitoring interaction. Examples include pushing or pulling non-monitoring data to or from an external system, or causing action in a remote system or allowing a remote system to cause action within Zenoss.

Platform Extension

A Zenoss platform extension is defined as any functionality that doesn’t interact with outside systems. The provided functionality is instead used directly by users or by other parts of the Zenoss platform, or by other ZenPacks.


Maintainer

The maintainer of a ZenPack is the organization or individual that controls the code repository for a ZenPack and is the gate for all changes including defect and enhancement resolution. The following categories are mutually exclusive.

Zenoss Engineering

Maintained by the product engineering organization at Zenoss, Inc. Ongoing support is provided by Zenoss, Inc. at the same level as the Zenoss platform software for customers with an active subscription.

Zenoss Services

Maintained by the services organization at Zenoss, Inc. Ongoing support is provided under a statement of work.

Zenoss Community

Maintained by a member of the Zenoss community. Ongoing support is subject to the individual maintainers’ control, and is typically provided in the community web forums, mailing lists and IRC channel.


Availability

Who has access, license and permission to use the ZenPack. The following elements are mutually exclusive.

Open Source

ZenPack source and packages are available as free open source. Designed to function properly on a Zenoss system with or without commercial-only ZenPacks installed.

Available with Zenoss Subscription

ZenPack packages are available at no extra cost to anyone with a Zenoss subscription, but are not installed by default. May have dependencies on Open Source ZenPacks or other ZenPacks that are Available with Zenoss Subscription.

Additional Cost with Zenoss Subscription

ZenPack packages are available at an additional cost on top of an existing Zenoss subscription. May have dependencies on Open Source ZenPacks, ZenPacks that are Available with Zenoss Subscription, or other ZenPacks that are Additional Cost with Zenoss Subscription.


QA Level

The level of automated, manual and field testing A ZenPack has. The elements are mutually exclusive.

Untested

Insufficient automated testing to qualify as Automatically Tested, and insufficient manual testing to qualify as Q.A. Tested.

Automatically Tested

Standard automated testing passes plus a minimum of 90% unit test code coverage with all tests passing.

Q.A. Tested

Tested, and passed, by the quality assurance group of Zenoss, Inc.


Complexity

Defined by the technical difficulty of implementing specific types of functionality within the ZenPack. The elements are not mutually exclusive, and most ZenPacks will implement multiple types of functionality as defined below. A rough total complexity score could be created for each ZenPack by summing the complexity score of all implemented elements.

Configuration

Built entirely in the web interface. No programming knowledge required.

Complexity:1
Skills:Zenoss
Example:ZenPacks.zenoss.IISMonitor

Scripts

Scripts can be written in any language and do anything. Since all Zenoss customizations should be packaged as ZenPacks, they’re only included in ZenPacks as a packaging mechanism. They might not have any direct interaction with the Zenoss platform.

Complexity:2
Skills:Scripting (Any Language)
Example:ZenPacks.zenoss.RANCIDIntegrator

Command DataSource Plugins

Command datasource plugins can be written in any language and executed either on the Zenoss server, or remotely using SSH. Without writing a custom parser (see next item) they must write to STDOUT using either the Nagios or Cacti output formats and exit using the appropriate Nagios or cacti exit code.

Complexity:2
Skills:Scripting (Any Language)
Example:ZenPacks.zenoss.ApacheMonitor

Event Class Transforms and Mappings

Built in the web interface. Basic Python knowledge required.

Complexity:2
Skills:Zenoss, Basic Python
Example:ZenPacks.zenoss.OpenStack

Command DataSource Parsers

Command datasource parsers must be written in Python and conform to the Zenoss CommandParser API. These parsers must be written to extract extended data from the output of command datasource plugins (see previous item), or to handle output that doesn’t conform to the Nagios or Cacti output formats.

Complexity:3
Skills:Zenoss, Python
Example:ZenPacks.zenoss.SolarisMonitor

DataSource Types

When a new datasource is added in the web interface you must choose the type. Creating a DataSource type in a ZenPack is a way to add new types to this list. The ApacheMonitor ZenPack listed as the example below adds the ability to collect performance metrics from an Apache httpd server using mod_status.

New DataSource types are written in Python and must subclass RRDDataSource or one of its existing subclasses. Additionally an API adapter must also be written in Python to define the user interface to the datasource properties.

Complexity:4
Skills:Zenoss, ZCML, Python
Example:ZenPacks.zenoss.ApacheMonitor

Impact Adapters

There are three types of impact adapters. All are written in Python and added to the system configuration through ZCML directives.

The first is a state provider. These implement the IStateProvider interface and allow manipulation of how a given node type’s state within the impact graph is calculated.

The second is a relations provider. These implement the IRelationshipDataProvider interface and allow manipulation of what other nodes a given node type impacts, and what other nodes impact it.

The third is a triggers provider. These implement the INodeTriggers interface and allow manipulation of the default impact policies set on a given type of node.

Complexity:5
Skills:Zenoss, ZCML, Python
Example:ZenPacks.zenoss.ZenVMware

ETL Adapters

ETL is used to export model, performance and event data from a Zenoss instance to a Zenoss Analytics instance. However, ETL adapters only need to be written to manipulate the model data that is exported. There are two types of ETL adapters. They’re both written in Python and added to the system configuration through ZCML directives.

The first type is a reportable. These implement the IReportable interface and allow precise control over which properties of an object type are exported, and how they’re named and manipulated for export.

The second type is a reportable factory. These implement the IReportableFactory interface and all manipulation of which objects are considered for export. By default all devices and components are considered for extraction so a reportable factory is usually only used when fine-grained control over the relationships between these objects is needed.

Complexity:4
Skills:Zenoss, ZCML, Python
Example:ZenPacks.zenoss.ZenVMware

User Interface

Modifications to the existing user interface, or entirely new sections of user interface. The difficulty of these changes varies considerably. See the Skills field below for the range of skills that could be required to make these kinds of changes.

The ServiceNowIntegrator example given below adds a new button to the event console that pops up a new dialog box with some custom options available. Only ZCML and JavaScript were required for this type of change.

TAL is usually only required when editing or creating old-style pages that aren’t entirely built using ExtJS.

Complexity:5
Skills:Zenoss, ZCML, TAL, JavaScript, ExtJS
Example:ZenPacks.zenoss.ServiceNowIntegrator

Modeler Plugins - SNMP, COMMAND, WMI

Modeler plugins provide the mapping between data collected from the environment and the Zenoss model. In the case where the data can be collected using SNMP, COMMAND (run a command remotely via SSH) or WMI, there is existing infrastructure to make these tasks easier. However, the modeler plugins are still written in Python.

If collecting using SNMP the SnmpPlugin class can be extended to do the hard parts of SNMP gets or walks for you. If collecting by running a command on a remote system via SSH, the CommandPlugin class can be extended to do the hard parts of SSH and output parsing for you. If collecting from a Windows system using WMI, the WmiPlugin class can be extended to do the hard parts of WQL querying for you.

The only significant logic that must be implemented in these cases is turning the returned data structures into ObjectMap and RelationshipMap objects to apply to the Zenoss model.

Complexity:6
Skills:Zenoss, Python, (SNMP, Scripting or WMI)
Example:ZenPacks.zenoss.SolarisMonitor

Modeler Plugins - Python

See Model Extensions above for what modeler plugins are. Python modeler plugins only differ in that you extend the PythonPlugin class, and must implement the collection logic in addition to the processing logic.

The collect method implementation may return data normally, or it may return a Twisted deferred to take advantage of the asynchronous modeling engine. It is recommended to use the deferred approach whenever possible to avoid blocking the zenmodeler daemon while the collect method executes.

Complexity:7
Skills:Zenoss, Python, Twisted
Example:ZenPacks.zenoss.OpenStack

Model Extensions

When the standard model of the Zenoss platform doesn’t cover an object or property you need in your ZenPack, the model can be extended. Existing model classes such as Device, FileSystem or IpInterface can be extended, and entirely new types of components can be created.

The typical requirements for extended the model include at least the following steps.

  1. Create a Python class
  2. Create an API interface and adapter
  3. Wire up the API with ZCML
  4. Write JavaScript to tailor the display of your component
  5. Write a modeler plugin
Complexity:8
Skills:Zenoss, ZCML, Python, JavaScript
Example:ZenPacks.zenoss.OpenStack

Daemons

A new daemon must be written only if none of the existing daemons can perform the task required by your ZenPack. The zencommand daemon is the usual last resort for custom collection requirements if none of the more specialized daemons will work. See Command DataSource Plugins and Command DataSource Parsers for what can be done by zencommand.

There is a common collector framework that should be used to perform much of the typical daemon functionality such as configuration and scheduling in a consistent way. To use this you should create a CollectorDaemon object, configure it with a class that implements the ICollectorPreferences interface and create a task class that implements the IScheduledTask interface.

In almost all cases you will also need to create a ZenHub service to build the configuration for your new daemon. This service should subclass HubService or one of its existing more specialized subclasses.

Complexity:9
Skills:Zenoss, Python, Twisted
Example:ZenPacks.zenoss.ZenVMware

Platform Extension

Platform extensions are any implementations added to a ZenPack that doesn’t fall into any of the previously-defined complexity elements. Due to the flexibility of ZenPacks, these could be almost anything.

The DistributedCollector example given below falls into this category because it extends the simple flat collector structure in the core Zenoss platform to be a tiered hub and collector structure. It also adds extensive hub and collector management capabilities.

Complexity:10
Skills:Zenoss, ZCML, Python, JavaScript, etc.
Example:ZenPacks.zenoss.DistributedCollector

Example ZenPack Classifications