Zenoss divides data collection into two parts: modeling, and performance collection. During the modeling, or discover step, the external world is sampled through a series of plug-ins. The result of the discovery step is a generic "Map": a nested data structure that mimics the structure of the components within a device.

#

Figure 11.1. Modeling Overview

For example, we can query the list of network interfaces on a device using SNMP. We will map that into a data structure to mimic the path on the device:

  { 'os' : { 'interfaces' { 'eth0': { 'type': 'ethernetCsmacd',
                            'speed': ... }
                          { 'eth1': { 'type': 'ethernetCsmacd',
                            'speed': ... }
    

These dictionaries of collected data are called DataMaps. There is a set of recursive functions that walk the maps and apply the values to the device, creating components and setting values on them. In this way, a remote collector can push updated configuration back to the central database without concern as to what the current configuration is, and what exactly should be updated.

The Zenoss plugins are specialized to easily create these maps. Typically they consist of a single method process() to transform SNMP query results into DataMaps. The plugin specifies the SNMP tables to be scanned, and the process method is used to transform the results into DataMaps. Some plugins can test their applicability to a specific device. For example, the plugin may only be appropriate if the device supports SNMPv2, or has a particular agent OID. These plugins have a "test" method which is run before the plugin is used by the modeler.

SSH plugins, which are very much like SNMP plugins, transform output of various commands into datamaps. For example, the output of the Unix df command is transformed into a map to create and update file system information.