Zenoss Core 3.x Network and System Monitoring: A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system

Zenoss, Inc., makes several installation packages of Zenoss Core available to meet the needs of its community. For a list of current installation packages, visit www.zenoss.com/download. You'll find native packages, stack installers, and source files for several operating systems: Red Hat Enterprise Linux, Centos, Ubuntu, Fedora Core, OS X, OpenSuse, and Debian. The stack installers and native packages include all Zenoss Core dependencies.

If you need a no fuss installation to use as a sandbox or to follow along with the book, then I recommend loading one of the Zenoss Core VMware appliances for Windows, Linux, or OS X. To run the appliance, download the VMware Player or VMware Server for free from www.vmware.com.

One of the first questions we need to answer is, "How will I collect information from my devices and services?" Zenoss Core supports the following ways to model (collect data from) the device:

SNMP gives us the most flexibility and the best device support. WMI lets us access information about services running on Windows servers and can co-exist with SNMP. If we want to monitor Windows event logs, then WMI is a must.

Even if your device supports SNMP, there may be times when you are unable to use it. For example, you're monitoring a remote device that's outside the local network. Zenoss, Inc., distributes a suite of command-line monitors that can be installed on a device via the Zenoss Plugins, and Zenoss Core runs the plugins over an SSH or Telnet session to collect the performance data.

In the unfortunate event that your device doesn...

Both the Zenoss Core server and the monitored devices have port requirements. The Zenoss Core server needs to allow access to the following ports:

To facilitate monitoring, the systems on the network need to allow access to the following ports:

This is a common list of ports, but network and monitoring needs are unique from one site to the next. For example, if you do not plan to monitor any devices with the Zenoss Plugins over Telnet, then don't open port 23 on your monitored devices.

New installations automatically run a setup wizard that creates a user account, defines an administrator password, and discovers devices attached to the network. Many of you have probably already breezed through this step, but we'll step through the process for the benefit of those of you who are working through an initial install.

Even if you already ran the initial setup wizard, you can invoke the add device wizard by selecting the Add Multiple Devices... link on the Infrastructure | Devices page. See the following screenshot:

Step 1: Setting up users

If this is a new installation, you will be greeted with the setup wizard when you visit the Zenoss Core application. Otherwise, you will see the Zenoss Core Dashboard.

Click the big green arrow to advance the wizard...

We've seen how you can autodiscover the devices on your network, but you may not want to monitor all of the discovered networks. For example, you may have workstations, test servers, and other systems not worth monitoring. By adding a single device at a time, you can also specify device attributes, including classes, SNMP properties, serial numbers, notes, and more.

The Add Single Device option is available by clicking on Infrastructure | Devices. See the following screenshot:

The Add a Single Device window displays as a pop up with the option to add several device attributes:

The advantage of adding devices from this view is that we can add a device with a specific set of properties. The wizard didn't give us this kind of flexibility.

So far, we've seen ways to build our device inventory through the web interface. In one case, we auto-discover everything and in the other case, we add the devices one at a time.

What if you already have a list of the SNMP capable devices by hostname or IP address? Wouldn't it be nice to import those devices. Zenoss Core can import a list of devices and attributes via the zenbatchload command.

In its simplest form, zebatchload will process a text file that lists one device per line. Here's a sample list of devices that I will call deviceList.txt:

device01
router02
web03

Since zenbatchload is a Zenoss Core daemon, we need to run it as the zenoss user. Here are the commands:

su – zenoss
<enter zenoss user's password>
zenbatchload deviceList.txt

The zenbatchload command will attempt to run SNMP on each device. If the device doesn't support SNMP, it won't be added to the inventory. The zenbatchload command accepts device classes, options, and zProperties...

The zendisc daemon gives us an opportunity to discover devices from the command line. It can be a helpful troubleshooting tool, or it can be a way for you to shed the Web interface and satisfy your curiosity about how Zenoss Core works. Let's take a look at a few example commands.

To see a list of available options, run the following command as the zenoss user:

zendisc help

Let's work through an example where we remodel a device on our network. Modeling the device gives Zenoss Core the characteristics about the device that we monitor. Sometimes Zenoss Core may not be collecting the information we think it should, so we need to figure out why.

Run the following command as the zenoss user:

zendisc run --remodel -d coyote --logseverity=10

Because we used the --logseverity=10 option, the output is verbose and we can step through the remodeling process, one line at a time. A value of 10 provides the highest level of verbosity.

The -d coyote option ran the --remodel...

In order to monitor a device, we need to tell Zenoss Core how to monitor the device. Our options include SNMP, WMI, or Zenoss Plugins over SSH. Then we have to make sure the monitored devices are configured to respond to the monitoring protocol Zenoss Core uses for each device.

As you look at your Zenoss Core device list, you should see a list of devices. However, you may see several events that indicate Zenoss Core is not able to model devices correctly. Events could also signify there's a problem with the monitored device, but we're just starting out. It's more likely we need to tweak the monitoring properties of each device.

A common point of failure in establishing the relationship between the monitoring server and monitored device is credentials. If you are having problems, make sure Zenoss Core can authenticate using the unique credentials for each device.

Our monitoring protocols also require access to specific ports. In this chapter, we outlined the common ports that Zenoss...