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
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Event Attributes
Device Attributes
Example snmpd.conf
Index

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:

${evt/attribute}

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:

evt.attribute

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

Event Attribute

Description

dedupid

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

evid

A unique identifier for the event.

device

Specifies the device attached to the event.

component

The Zenoss daemon reporting the event.

eventClass

The event class that the event maps to.

eventKey

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

Summary of the event.

message

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

severity

A Numeric representation of the event:

  • 5 = Critical

  • 4 = Error

  • 3 = Warning

  • 2 = Info

  • 1 = Debug

  • 0 = Clear

eventState

Numeric representation of the event state:

  • 0 = New

  • 1 = Acknowledged

  • 2 = Suppressed

eventClassKey

Maps the event to an event class.

eventGroup

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

stateChange

Time stamp when the event state changed.

firstTime

Time stamp when the event first occurred.

lastTime

Time stamp when the event last occurred.

count

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

prodState

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

  • 1000 = Production

  • 500 = Pre-Production

  • Test = 400

  • Maintenance = 300

  • Decommissioned = -1

suppid

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

manager

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

agent

Reports the Zenoss daemon responsible for generating the event.

DeviceClass

The device class.

Location

The location organizer assigned to the device.

Systems

The system organizer assigned to the device.

DeviceGroups

The group organizer assigned to the device.

ipAddress

The IP address of the device.

facility

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).

priority

The priority of the syslog event.

ntevid

The Event ID field of the Windows NT event log.

ownerid

The ID number of the event owner.

clearid

The ID number of the event that cleared this event.

DevicePriority

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

  • 5 = Highest

  • 4 = High

  • 3 = Normal

  • 2 = Low

  • 1 = Lowest

  • 0 = Trivial

eventClassMapping

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