Let's get our devices in shape to be modeled.
When we talk about Zenoss Core, two related terms often come up, monitoring and modeling. Monitoring refers to the availability of the device and answers the question, "Is the device accessible?". Modeling defines relationships between devices and identifies the components available on a device, such as services, interfaces, and file systems. It then collects varying amounts of data about each component.
Zenoss models devices via WMI, SNMP, SSH/Telnet, and port scan. Each class has a default set of collector plugins that tells Zenoss how to model the devices assigned to the class.
Remember in Chapter 2, Discovering Devices when we set up our servers to be monitored by setting up WMI, SNMP, and the Zenoss plugins? Now is the time to put that work to use. Feel free to go back and review that section now.
As we model our servers, routers, and other network devices, we'll be interested in setting the collector plugins and zProperties for each device.
Each modeler plugin queries the device for a specific set of information that it will store in Zenoss Core's device database. What we collect depends on multiple factors, such as the capabilities of the device and the modeler plugins assigned to the device. In general, we can expect to collect information about the operating system, file systems, interfaces, routes, processes, IP services, CPU, and memory.
Note
Modeler plugins can be assigned at the class level. However, we can configure exceptions from the class properties at the device level.
Let's examine these modeler plugins I've been talking about.
- From the Infrastructure menu, select Devices.
- Navigate to the /Servers/Windows class.
- Click on the Details button to display a list of settings.
- Find and click the Modeler Plugins link to display a sortable list of plugins.
A page showing the assigned collector plugins displays in the left column of the page with an Add Fields link on the right.
To see a list of unassigned plugins click on the Add Fields link.
The plugin names are intuitive in that the name suggests the type of information we expect to collect. For example, zenoss.snmp.IpServiceMap uses SNMP to return a list of active IP services on the device, such as HTTP. The Dell-specific plugins retrieve more detailed information from Dell devices using OpenManage, and the HP plugins provide more information about devices using Insight Management agents.
The plugins follow a three part naming convention. The first part identifies the author (for example, zenoss). The second part lists the collection method (for example, SNMP, WMI, cmd). The final part identifies the specific information collected by the plugin (for example, IpServiceMap, CpuMap, uname).
Actually, the command plugins, identified by the "cmd" in the name, have an optional field to specify system architecture. For example, cmd.linux applies to Linux servers while cmd.darwin plugins apply to OSX.
To remove a plugin from the assigned plugin list, click on the x next to the plugin name. To assign a plugin, drag the plugin name from the available list to the assigned list.
Take the time now to review the devices in your inventory and set the appropriate collector plugins. If you're not sure where to start, consider the following questions as a starting point:
- Will you monitor with WMI? If not, remove the
zenoss.wmi.WinServiceMapplugin. - Does the device support SNMP? If not, remove the
snmpplugins. - Is the server a Dell or HP? If so, add the PowerwareDeviceMap or SysedgeDiskMap and SysedgeMap plugins.
- Are you monitoring a remote OSX server with the Zenoss Plugins? If so, add the
zenoss.cmd.darwinplugin. - Plan to rely on port scan? Then use the port scan plugin.
Obviously, we can't cover every possible scenario; however that should get you started.