Zenoss Core 3.x: Device Setup and Administration

April 2011


Zenoss Core 3.x Network and System Monitoring

Zenoss Core 3.x Network and System Monitoring

Implement Zenoss core and fit it into your security management environment using this easy-to-understand tutorial guide.

        Read more about this book      

(For more resources on the subject, see here.)

We'll spend the bulk of this article fine-tuning our device inventory and getting it into monitoring shape. One of Zenoss Core's critical concepts is inheritance, which means that the devices inherit monitoring properties from their parent device class.

We can change the monitoring rules at the device level by tweaking individual device properties, called zProperties.

Let's start by taking a look at some of Zenoss Core's organizers.

Organizing devices in Zenoss Core

Zenoss Core provides multiple ways to organize our devices. We're going to take a closer look at Locations, Systems, Groups, Networks, and Classes. Collectively, these organizers allow us to describe devices in a way that's meaningful to your organization.

We can define the organizers to be as specific as we need them to be, and not all organizers are required. In other words, no one will care if you do not define any groups. The information that we do specify can be used to establish monitoring rules, event handling, and alerting rules.

Let's start by adding a location.


Zenoss Core does not include any location organizers by default. To add a location, click on the Infrastructure menu. A list of organizers displays in the left sidebar of the page, as seen in the following screenshot:

Zenoss Core 3.x: Device Setup and Administration

Potential location names are floors, buildings, wings, room numbers, or office locations. Use something that's meaningful to you.

To enter a new location:

  1. Select Locations from the sidebar of organizers.
  2. Click the plus sign (+) at the bottom of the sidebar to Add a child to the selected organizer to display the Add Location dialog:

    Zenoss Core 3.x: Device Setup and Administration

  3. Enter the Name of the location, a Description, and an Address.
  4. Click on SUBMIT to add the location:

    Zenoss Core 3.x: Device Setup and Administration

Enter anything you think may be important about the location of that device. For example, phone extension, driving directions, or site contacts may be practical items to include in the description.

The real-world address may be something you want to record about a location, especially if you have multiple locations. Zenoss Core provides a separate Address field for each location name that ties into the Google Maps portlet.

The Google Maps portlet displays your locations on a map and connects them for some nice dashboard eye candy. If a marketer happens to come by, be sure to show them the Google Maps portlet. You may make a friend.

We can add as many locations as we need, or we can define a hierarchy of locations by adding a sub-location. To add a sub-location, click on the name of the location from the list and click on the Add a child to the selected organizer button.

Systems and Groups

Groups are closely related to Systems and how you use them is an exercise of your imagination or operational needs. As an example, you might use groups to define nodes on the org chart while the Systems describe the devices in terms of function. In my monitoring environment, I group websites by project manager, so my groups are names of people. I don't define any "systems" organizers, but you can. There's no wrong answer.

Systems and Groups are displayed in the same spot as the locations, by clicking on the Infrastructure menu. Adding either a system or a group works the same way, too. Click on either System or Group, and then click the Add a child to the selected organizer button. Enter the Name and Description, as shown in the following screenshot:

Zenoss Core 3.x: Device Setup and Administration

Adding a system is the same as adding a group, except that you select the Systems organizer in the sidebar first.

Organizer details

Before we look at classes, let's take a quick look at how we can work with Locations, Groups, and Systems in the Zenoss Core interface.

You will notice that as you click on an organizer, the device list filters to include all the devices assigned to an organizer. We haven't assigned any devices to an organizer yet, so the device list is empty. However the following screenshot shows an established Zenoss Core installation:

If you click on the Details button, the sidebar changes to display the following items: Devices, Events, Administration, Map, and Modifications.

Zenoss Core 3.x: Device Setup and Administration

If you click on the Events link, you see all the events associated with that organizer.

Click on the Administration link to display a list of commands, maintenance windows, and device administrators.

The Map page displays a map of the location based on the address information you entered for the organizer. The map requires a Google Maps key.

To see a list of changes for the device, click on the Modifications link.

To exit the Details page, click on the See All button.

Editing organizers

You can change the name or description of an organizer by selecting the organizer and then clicking on Edit. You can find the Edit option by clicking on the Actions menu button (which looks like a sprocket) at the bottom of the Infrastructure sidebar. See the following screenshot:

Zenoss Core 3.x: Device Setup and Administration

Moving organizers

You can nest organizers by dragging and dropping one organizer into another one to create a hierarchy. You can only nest similar organizers, which means that you cannot move a system into a group or a group into a location.


Classes provide one of the most important organizers in Zenoss Core because we can use the classes to establish monitoring properties for groups of devices. Each device inherits the properties of its parent class. Using classes, we can define specific monitoring rules and settings via zProperties. All devices in a class share the same zProperties.

Classes also define what types of information Zenoss Core collects about a device by assigning a set of collector plugins. Like the zProperties, each class contains a set of collector plugins that can change from one class to another.

The Zenoss Plugins that we install on remote Unix servers are not the same as the collector plugins we configure for our devices.

Several classes exist to organize devices, events, services, and processes based on common groupings, but we'll stick to talking about devices right now.

Viewing a list of device classes

You have probably already noticed that the list of device classes is available when you click on the Infrastructure menu. Zenoss Core includes a default hierarchy of classes; for now, we'll work within those default classes.

Next to each class is a number within parenthesis that indicates the number of devices that are associated with the class, including the sub-classes. The icon to the left shows the highest severity event for each class.

Click on the class name to display all the devices assigned to that class.

A devices can only be assigned to one class.

A hierarchical list of the default device classes in Zenoss Core follows. However you can add as many classes as you want.

List of device classes

  • Discovered
  • KVM
  • Network
    • Router
    • Cisco
    • Firewall
    • RSM
    • Terminal Server
    • Switch
  • Ping
  • Power
    • UPS
      • APC
  • Printer
    • InkJet
    • Laser
  • Server
    • Cmd
    • Darwin
    • Linux
    • Remote
    • Scan
    • Solaris
    • Windows

Assigning devices to a class

Depending on how you added devices, you may need to reclassify them. For example, if you auto discovered your network, all the devices in your inventory will be classified as /Discovered. There's no long term value in that.

To assign devices to a class:

  1. Click on the Infrastructure menu to display a list of all devices.
  2. Select one or more devices.
  3. Drag and drop the selected devices onto the appropriate device class.
  4. Click on OK when prompted to confirm the move.

Zenoss Core 3.x: Device Setup and Administration

The screenshot shows the device named coyote being moved to the /Server/Linux class. Notice that the interface is giving you some feedback. You can only assign a device to one class, so the selected class is highlighted.

The tool tip box in the screenshot is showing 1 selected row, which corresponds to the number of devices you're adding to the class. In the screenshot, only one device is being moved to /Server/Linux.

After you classify the devices, it's time to model them.

        Read more about this book      

(For more resources on the subject, see here.)

Modeling devices

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.

As we model our servers, routers, and other network devices, we'll be interested in setting the collector plugins and zProperties for each device.

Modeler plugins gather device information

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.

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.

  1. From the Infrastructure menu, select Devices.
  2. Navigate to the /Servers/Windows class.
  3. Click on the Details button to display a list of settings.
  4. Find and click on the Modeler Plugins link to display a sortable list of plugins.

Zenoss Core 3.x: Device Setup and Administration

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.

Any change we make to the collector plugins at the class level will be applied to all devices in the class. If we have one-off changes, we should make the changes at the device level.

Assigning modeler plugins

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.WinServiceMap plugin.
  • Does the device support SNMP? If not, remove the snmp plugins.
  • 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.darwin plugin.
  • 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.

Troubleshooting data collection

Wouldn't it be nice if everything just worked? Unfortunately, we can expect to make a mistake or two.

Troubleshooting SNMP problems

If you see an event in Zenoss that reports SNMP agent down, we first need to find out whether the issue is with Zenoss Core or with the device.

Not all network devices support SNMP. So, before you beat yourself up troubleshooting, make sure your device supports SNMP.

Running snmpwalk

Zenoss Core includes a command that will run the snmpwalk command on the selected device. The snmpwalk command will query the device using the SNMP community string we assigned to the device and will try to get a list of the OIDs. Let's try it.

Navigate to Infrastructure and select Devices. Select a device (by clicking on the device name) that should respond to SNMP requests. The device's Overview page displays.

  1. At the bottom of the sidebar, expand the Commands menu and select snmpwalk.
  2. The command runs against the device and returns the result, as shown in the following screenshot:

The previous screenshot indicates that Zenoss Core was able to retrieve data from the device successfully. If you have problems, the snmpwalk command will either timeout or be refused.

If you're having problems connecting, check the SNMP Community attribute (zSnmpCommunity) from the Configuration Settings of the device to make sure it's correct.

If problems continue, let's move to the device itself and run the snmpwalk command, assuming we're working with a Linux server.

Run this command on the problem device:

snmpwalk -c public -v 2c localhost

If the command is successful, pages of results will scroll by the terminal. You should check to make sure the device is allowing incoming connections on port 161/UDP and that both the device and Zenoss Core are using the correct community strings.

Is the SNMP daemon running on Linux servers?

You should also check to make sure the snmpd daemon is running. Run the following command to check:

ps aux | grep snmpd

We expect to see /usr/bin/snmpd running in the process list.

If you are still having problems, review the SNMP zProperties for the device. You can try different SNMP versions and make sure SNMP monitoring is enabled. To find the zProperties for a device, navigate to the device's status page. Then click on the Configuration Properties link.

A description of the zProperties of all devices is included at the end of this article.

SNMP problems on Windows

Assuming the snmpwalk fails when run from Zenoss Core, make sure SNMP is installed on the server.x

The built-in Windows SNMP client doesn't provide as much information as Net-SNMP does for our Unix-based systems. You may be wondering why Zenoss Core isn't collecting file system information or CPU statistics. You need a third-party SNMP agent for Windows. Try the free SNMP agent from http//:www.snmp-informant.com.

Troubleshooting WMI problems

The first thing you should do is to make sure you have WMI installed.

Zeneventlog—unable to connect to Windows

If you see an event that indicates zeneventlog is unable to connect to Windows, that's an indication Zenoss Core is not able to authenticate to the Windows server. Check the Configuration Properties (zProperties) of the device to ensure you have the correct username and password set.

The following screenshot shows the WMI specific zProperties:

Zenoss Core 3.x: Device Setup and Administration

Remember, the zWinUser and zWinPassword properties must be an administrator on the Windows server you're monitoring. It's possible that each of your Windows servers could require a different username and password.

The zWinUser property can be either a local or a domain account. If you use a domain account, specify the domain for the zWinuser value (for example, mojoactive\administrator).

Zenoss Core does not collect WMI data

It's possible that Zenoss Core isn't collecting any data from the Windows Servers via WMI, but there are no events reported. You can check the following zProperties at the device or class level:

  • Make sure the device is using the zenoss.wmi.WinServiceMap collector plugin
  • Set the zWmiMonitorIgnore property to False in the Configuration Properties for the device or device class
  • If you want to collect event logs, set the zWinEventlog property to True in the Configuration Properties for the device or device class

Troubleshooting Zenoss Plugins

We installed the Zenoss plugins on Unix hosts that we may not be able to monitor with SNMP, such as remote Linux or OSX servers. If you're encountering problems, there are several zProperties that affect how successfully you can monitor remote machines. See the following screenshot:

Zenoss Core 3.x: Device Setup and Administration

There are several points of failure, but the most probable error is that the zCommandPath value is not valid if you installed the Zenoss Plugins as I described. The zenplugin.py file is installed to /usr/bin. And as you can see, the zCommandPath is pointing to /usr/local/zenoss/libexec. This means that each time Zenoss Core tries to collect data from the device using the remote command, it's trying to run /usr/local/zenoss/libexec/zenplugin.py on the remote server.

Change the zCommandPath property to reflect the actual path to zenplugin.py on the remote server, such as /usr/bin.

In order for Zenoss Core to connect to the remote server, it must supply valid user credentials. Check the zCommandUsername and the zCommandPassword properties to ensure they contain a valid username and password for the remote server.

A class of its own

Zenoss Core provides the /Server/Cmd class specifically for monitoring remote machines. The collector plugins are specifically designed to interact with zenplugin. py and retrieve data about the remote server. The following screenshot shows the collector plugins assigned to the /Server/Cmd class.

Zenoss Core 3.x: Device Setup and Administration

You won't find any SNMP collectors here.

        Read more about this book      

(For more resources on the subject, see here.)

Device administration

In this section, we'll take a look at some basic device administration tasks, including: rename a device, delete a device, reset the IP address, and lock the device's configuration.

Locking or unlocking a device

Zenoss Core automatically polls the devices in our inventory and remodels the devices when it finds changes. To prevent changes to the device properties, we can lock the configuration, and we can also lock the device from being deleted from the inventory.

To change the lock status of a device:

  1. From the Device Overview page, select Lock from the Actions menu.
  2. Select from these choices, as shown in the following screenshot:
    • Lock from updates
    • Lock from deletion
    • Send event when actions are blocked

      Zenoss Core 3.x: Device Setup and Administration

  3. The device status page displays after we choose a locking option.

The options should be self explanatory. If you choose to send an event when actions are blocked by a lock, the event will show up in the event console for the device.

Renaming a device

Zenoss automatically detects and populates the device name, but we can name the device anything we want. On my test network, I prefer to use the names of furbearers.

  1. From the Device Overview page, select Rename Device from the Actions menu.
  2. Enter the new name (for example, Coyote) in the ID field of the Rename Device dialog.
  3. Click on OK to save the change.

On the Device Status page, the device information updates to reflect the new name. Even the breadcrumb navigation changes to reflect the new name.

Zenoss Core 3.x: Device Setup and Administration

Now, you can manage your devices using whatever slang you wish.

Resetting the IP address

Sometimes we need to move machines around and allocate new IP addresses. At other times, we may try to monitor a server only to discover that it has a dynamic IP address. Since Zenoss Core requires a static IP address on the monitored device, we need to assign an IP address to the server, and therefore, IP information will need to be updated in Zenoss Core.

To change the IP address:

  1. From the Device Overview page, select Reset/Change IP from the Actions menu.
  2. Enter the new resolvable hostname or IP address in the IP Address field of the Reset/Change IP dialog box (shown in the following screenshot) or leave it blank to allow Zenoss to lookup the IP based on the device name.
  3. Click on OK to save the change.

    Zenoss Core 3.x: Device Setup and Administration

Push changes

After we make changes to the device, we can "push" the changes to the collectors right away instead of waiting for Zenoss Core to remodel the device. From the Device Overview page, select Push Changes from the Actions menu.

Zenoss Core confirms the action with a status message in the bottom-right corner of the page.

The collectors in Zenoss Core define settings that determine how each device assigned to a collector is monitored. For example, we can configure the default cycle times for the modeler protocol (SNMP, WMI, Ping). On Zenoss Core, the default collector is localhost. Zenoss Core supports only one collector on the same host.

Deleting devices

Given enough time, we will find devices in our inventory that we want to delete. For example, maybe we accidentally added a bunch of workstations with dynamic IP addresses that go up and down. There are many other reasons to delete a device from Zenoss Core, but I trust you have a firm grasp on when deleting a device from the inventory is necessary.

If you think you might want to monitor the device in the future, you should consider setting the production state to decommissioned. This keeps all the historical data and retains the device in the inventory; however, it's no longer monitored.

To remove a device from inventory:

  1. Click on the Infrastructure menu and select the devices you want to remove.
  2. From the Device Overview page, select Delete from the Actions menu.
  3. Select the Remove Devices button (it looks like a minus sign) located at the top of the device list.
  4. The Remove Devices dialog displays and prompts you to select from the following options:
    • Delete current events for these devices
    • Delete performance data for these devices
  5. Make the appropriate selections and click on OK to confirm the delete.
  6. The device will no longer show in inventory and Zenoss Core will no longer monitor it.

If you choose to retain the performance data by not deleting it, the data will be available to the device should we decide to add the device back to Zenoss Core at a later time.

zProperties defined

Throughout this article, we've seen several specific examples of zProperties, but there are many properties that impact how we monitor. The following table lists the device zProperties along with a brief description of the property. The zProperties are accessible via the Configuration Properties link at the device or class level.




Set the collector timeout in seconds. The default value is 180 seconds.


Specify the character encoding. The default is latin-1.


Set to true to log changes and false to not log changes to the collector.


Click the Edit link to open the collector plugin selection page.


Time in seconds to wait for a command to finish. The default is 15.


Specifies a time in seconds to cycle through zCommands. The default is 60.


Test to see if a command exists on the monitored device. The default is 'test -f %s'.


Wait the specified number of seconds for a login prompt to display. The default is 10.


Attempt to log in to the remote sever the specified number of times. The default is 1.


Enter the password for the user's shell account on the monitored device.


When you specify a command, Zenoss Core searches the specified path for the command. You can enter fully-qualified commands here.


The port the monitored system uses for remote connections. The default is 22 for SSH. Specify 23 for telnet.


Specify the protocol to use (Telnet, SSH). The default is SSH.


Not currently used.


Enter the user name for the remote device.


Enter the templates by name to use in order to display information. The default is device.


Enter the names of the file systems to ignore. For example: /boot.


Specify the file systems you want Zenoss Core to ignore.


Adjust the file system capacity values reported by Net-SNMP. Useful when the Linux server and Net- SNMP report different capacities.


A regular expression to match the names of hard disks.


Each device class has a default icon that can be changed as necessary.


Displays the interface description on the Interfaces table of the OS tab. Select either true or false. The default is false.


Enter the names of the interfaces to ignore. For example: lo.


Enter the type of interfaces to ignore. For example: local loopback.


Specify the maximum port number to port scan. The default is 1024.


Specify the path to the user's public key file for use with public-key authentication.


Enter HTML or TALES expressions to display content on the device's status page. For example, you can create a link to a router's administration console that will display on the Device Status page.


A regular expression match to identify local interface names. The default expression looks for lo (loopback) and vmnet (VMware).


A regular expression match to identify local IP address.


Specify the number of OIDs Zenoss collects with a single query. The default is 40.


Specify the options to use for the zenoss. portscan.IpServiceMap modeler plugin.


Select true to not ping the device or false to ping the device.


Monitor a service that is higher than the production state listed. Possible values include 1000 (Production), 500 (Pre-Production), 400 (Test), 300 (Maintenance), and -1 (Decommissioned).


Not currently used.


Set to true to collect only the indirect routes. Default is false.


Set to true to collect only the local routes. Default is false.


Specify the maximum number of routes to map. The default is 500.


Specify SNMP password, if applicable.


If using zSnmpAuthPassword, select either MD5 or SHA authentication protocol.


List of communities Zenoss tries to collect information for. The defaults are public and private. Enter more as needed.


The default community name on the monitored device.


Set whether or not Zenoss should monitor the device with SNMP. Defaults to false.


The SNMP communication port. It defaults to port 161.


Enter the security user's password.


Select either AES or DES encryption.


Enter the security user's name.


Length of time in seconds that Zenoss waits for a response from the remote SNMP agent. Defaults to 2.5.


Number of times Zenoss tries to connect via SNMP before reporting a failure.


The version of SNMP. Available options are 1, 2c, and 3. Defaults to 1.


Set the number of concurrent SSH sessions that Zenoss Core will make. The default is 10.


Specifies the time in seconds for an IP service to respond before the service is marked as down. The default is 15.


Not currently used.


On Cisco routers, send the enable command to enable command collection. Default is false.


Match the enable prompt with the specified regular expression.


Match the login prompt with the specified regular expression.


Match the password prompt with the specified regular expression.


Specify the time in seconds to wait for the login prompt to display.


Match the command prompt with the specified regular expression.


Select true to enable Telnet terminal length.


Specifies whether or not Zenoss collects the Windows event log. Default is false.


Collect all Windows event logs that match the specified severity. Enter a value between 1 and 5, where 1 is the most severe. The default is 2.


Enter the Windows user's password.


Enter the username of an account on the monitored Windows system.


Set to true to ignore WMI monitoring and set to false to monitor WMI services.


Set to true to enable XML/RPC monitoring.


At this point, the devices in your inventory should be organized and configured for monitoring. We defined the monitoring settings by assigning devices to classes, adding/removing collector plugins, and fine tuning the zProperties for the class or the individual device.

As we work with our devices and develop our Zenoss Core monitoring environment, we may realize that we want to change some of the work we did in this article. And that's no problem.

Further resources on this subject:

You've been reading an excerpt of:

Zenoss Core 3.x Network and System Monitoring

Explore Title