Book Image

Zenoss Core 3.x Network and System Monitoring

By : Michael Badger
Book Image

Zenoss Core 3.x Network and System Monitoring

By: Michael Badger

Overview of this book

For system administrators, network engineers, and security analysts, it is essential to keep a track of network traffic. Zenoss Core is an enterprise-level systems and network monitoring solution that can be as complex as you need it to be. And while just about anyone can install it, turn it on, and monitor "something", Zenoss Core has a complicated interface packed with features. The interface has been drastically improved over version 2, but it's still not the type of software you can use intuitively – in other words, a bit of guidance is in order. The role of this book is to serve as your Zenoss Core tour guide and save you hours, days, maybe weeks of time. This book will show you how to work with Zenoss and effectively adapt Zenoss for System and Network monitoring. Starting with the Zenoss basics, it requires no existing knowledge of systems management, and whether or not you can recite MIB trees and OIDs from memory is irrelevant. Advanced users will be able to identify ways in which they can customize the system to do more, while less advanced users will appreciate the ease of use Zenoss provides. The book contains step-by-step examples to demonstrate Zenoss Core's capabilities. The best approach to using this book is to sit down with Zenoss and apply the examples found in these pages to your system. The book covers the monitoring basics: adding devices, monitoring for availability and performance, processing events, and reviewing reports. It also dives into more advanced customizations, such as custom device reports, external event handling (for example, syslog server, zensendevent, and Windows Event Logs), custom monitoring templates using SNMP data sources, along with Nagios, and Cacti plugins. An example of a Nagios-style plugin is included and the book shows you where to get an example of a Cacti-compatible plugin for use as a command data source in monitoring templates. In Zenoss Core, ZenPacks are modules that add monitoring functionality. Using the Nagios plugin example, you will learn how to create, package, and distribute a ZenPack. You also learn how to explore Zenoss Core's data model using zendmd so that you can more effectively write event transformations and custom device reports.
Table of Contents (21 chapters)
Zenoss Core 3.x Network and System Monitoring
About the Author
About the Reviewers
Event Attributes
Device Attributes
Example snmpd.conf

Collection layer

The collection layer includes several daemons that gather information about devices, performance, and Events. They feed information to ZenHub to distribute to the appropriate database. The Zenoss Core daemons are easy to identify—they all start with the prefix "zen".

As the following screenshot illustrates, the Daemons page provides us with the complete view of the Zenoss Daemons that includes the process ID (PID) and up/down State. Green is up; red is down. From the interface, we can also view the Log File, edit the Configuration, and start and Stop each daemon.

If we browse the file system, we will find each daemon in $ZENHOME/bin. $ZENHOME is an environment variable, which allows us to talk about the Zenoss installation directory without knowing exactly where it is. For example, I may install to /usr/local/zenoss/zenoss while you install to /home/zenoss.

Twisted is an integral network communication protocol for the daemons. The Twisted Core README file describes Twisted as an "event-based framework for Internet applications"

Device management daemons

Finding the devices on our networks is a prerequisite to managing them, and Zenoss Core not only finds the devices, it models them. Device modeling builds a detailed overview of the network by recording the following types of information: system dependencies, available services, and change history.

The following table describes the daemons responsible for discovering and modeling devices:

Device daemon



Queries the devices via SSH/Telnet, SNMP, and port scans when we model the device. Each time zenmodeler runs on a device, it compares its findings with existing configuration and updates it as necessary.


Runs each time a request is made to discover a network or device.

Zenoss uses SNMP as a primary collection protocol. However, it can also collect information via ICMP pings, port scans, and plugins.

Performance and availability daemons

The Zenoss Core performance and availability daemons help us determine if the devices on our network are available and performing within our established guidelines. If our monitored systems perform in an unexpected way, Zenoss Core generates an event.

The following daemons play an important role in collecting performance and availability data:

Performance daemon



Stores the collected performance data in RRD files so that RRDtool can graph device performance over hourly, daily, weekly, monthly, or yearly durations.


Provides a way to run custom scripts and third party plugins including Nagios and Cacti plugins from within Zenoss.


Monitors the processes on Linux, Unix, and Windows systems.


Pings a device and reports an up or down status to determine if a device is active or not.


Tests the TCP ports and reports an up or down service.

Event daemons

When a device goes down or a service crosses a predetermined threshold, such as available disk space, Zenoss Core generates an event. Events can generate a notification alert or run a custom command (to automatically take remedial action to fix the event, for example).

Not only can Zenoss Core generate its own events, but it can collect events from external sources (for example, custom system administration scripts) and convert the information to a "Zenoss-style" event.

The following table outlines the Zenoss Core event daemons:

Event daemon



Creates events from syslog messages.


Creates events from Windows event logs.


Creates events from SNMP traps. When a problem occurs on a monitored device, it generates an SNMP trap to alert Zenoss of the problem.