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

Appendix A. Event Attributes

Throughout the course of this book, we've interacted with event attributes in many different contexts. As you might guess, these attributes define the details of an event in Zenoss Core. However, not all attributes are applicable to each event. The most obvious place to witness the event attributes and how they are applied is in the event log, which we covered in Chapter 6, Core Event Management. Also in Chapter 6, Core Event Management we reviewed event views, which determine how events show up in the event console—all predicated on the event attributes listed in this appendix.

We can also use the event attributes to process events in relation to:

  • Event transformations

  • Event mappings

  • Event commands

  • ZenPack programming

Your programming context determines how you access the event attributes. We can substitute the event attributes in our Python statements via TALES expressions, as we saw with the discussion of event commands in Chapter 6, Core Event Management.

An example of a TALES expression to access an event attribute looks like this:


The attribute can be any of the event fields defined in the following table. So if we wanted to write a TALES expression to access the message body of an event, the expression would look like this: ${evt/message}. Python evaluates the expression and substitutes the value into the current Python statement.

In other programming contexts where you might not use TALES, you would use the following syntax to access the event attribute:


The following table lists the available event attributes in Zenoss Core.

Event Attribute



Identifies the event so that Zenoss can deduplicate events. Takes the form of device, component, eventClass, eventKey, and severity.


A unique identifier for the event.


Specifies the device attached to the event.


The Zenoss daemon reporting the event.


The event class that the event maps to.


A user-defined way to map events. Event keys can be sequenced to aid the event class mapping of events from a common source to different event classes.


Summary of the event.


Message body for the event. May be the same as summary.


A Numeric representation of the event:

  • 5 = Critical

  • 4 = Error

  • 3 = Warning

  • 2 = Info

  • 1 = Debug

  • 0 = Clear


Numeric representation of the event state:

  • 0 = New

  • 1 = Acknowledged

  • 2 = Suppressed


Maps the event to an event class.


Event source group: For example, syslog, process, and ping.


Time stamp when the event state changed.


Time stamp when the event first occurred.


Time stamp when the event last occurred.


The total number of times the event has occurred based on the dedupid.


The production state of the device. The Zenoss defaults are:

  • 1000 = Production

  • 500 = Pre-Production

  • Test = 400

  • Maintenance = 300

  • Decommissioned = -1


If the event is suppressed, this is the ID of the suppressing event.


The fully qualified domain name of the event collector that generated the event.


Reports the Zenoss daemon responsible for generating the event.


The device class.


The location organizer assigned to the device.


The system organizer assigned to the device.


The group organizer assigned to the device.


The IP address of the device.


The syslog subsystem that generated the event (for example, cron, mail, lpr, auth, authpriv, daemon, ftp, kern, mark, news, syslog, user, uucp, local0 through local7).


The priority of the syslog event.


The Event ID field of the Windows NT event log.


The ID number of the event owner.


The ID number of the event that cleared this event.


The priority as assigned in the device's Edit page:

  • 5 = Highest

  • 4 = High

  • 3 = Normal

  • 2 = Low

  • 1 = Lowest

  • 0 = Trivial


The event class mapping used to evaluate and map the event.