Zenoss Administration Guide Zenoss

Zenoss Administration Guide

1. Introduction ............................................................................................................................... 1
1. Zenoss Overview ................................................................................................................ 1
1.1. The Zenoss Standard Model ....................................................................................... 1
1.2. Availability Monitoring in Zenoss ................................................................................ 1
1.3. Zenoss Event Management System .............................................................................. 2
1.4. Zenoss Performance Monitoring System ....................................................................... 2
2. Detailed Architecture ................................................................................................................... 3
1. Zenoss Detailed Architecture ................................................................................................ 3
2. User Layer ........................................................................................................................ 3
3. Data Layer ........................................................................................................................ 4
4. Collection and Control Services Layer .................................................................................... 4
4.1. Automated Modeling Daemons ................................................................................... 4
4.2. Availability Modeling Daemons .................................................................................. 4
4.3. Event Collection Daemons ......................................................................................... 5
4.4. Performance Monitoring Daemons .............................................................................. 5
4.5. Automated Response Daemons ................................................................................... 5
3. Key Concepts ............................................................................................................................. 6
1. Classification ..................................................................................................................... 6
2. zProperties ........................................................................................................................ 6
3. Inheritance and Path Navigation ............................................................................................ 6
4. Zenoss Interface and Navigation .................................................................................................... 7
1. Zenoss Dashboard ............................................................................................................... 7
2. Left Navigation Menu .......................................................................................................... 7
2.1. Main Views ............................................................................................................. 8
2.2. Classes ................................................................................................................... 8
2.3. Browse By .............................................................................................................. 8
2.3.1. Management ................................................................................................. 8
2.4. Hiding the Left Navigation Menu ................................................................................ 9
3. Directory Path .................................................................................................................... 9
4. Device/IP Search Box .......................................................................................................... 9
5. User Information Area ......................................................................................................... 9
6. Customizing Zenoss Dashboard Portlets .................................................................................. 9
6.1. Devices Issues Portlet .............................................................................................. 10
6.1.1. Configuring the Device Issues Portlet .............................................................. 10
6.2. Top Level Organizers .............................................................................................. 11
6.2.1. Configuring the Top Level Organizer Portlet ..................................................... 11
6.3. Watch List Portlet ................................................................................................... 12
6.3.1. Configuring the Watch List Portal ................................................................... 12
6.4. Google Maps Portlet ............................................................................................... 12
6.4.1. Configuring the Google Maps Portlet ............................................................... 12
6.5. Zenoss Issues Portlet ............................................................................................... 13
6.5.1. Configuring the Zenoss Issues Portlet .............................................................. 13
6.6. Production States Portlet .......................................................................................... 14
6.6.1. Configuring the Production States Portlet ......................................................... 14
7. Zenoss Network Map ......................................................................................................... 15
8. "Menu-ized" Elements ....................................................................................................... 15
8.1. Page Menus ........................................................................................................... 16
8.2. Table Menus .......................................................................................................... 16
5. User Management ..................................................................................................................... 18
1. About Zenoss User Accounts ............................................................................................... 18
2. Creating New User Accounts ............................................................................................... 18
3. Editing User Accounts ....................................................................................................... 19
3.1. Setting User Passwords ............................................................................................ 20
3.2. Editing User Contact Information .............................................................................. 20
3.3. Assigning Roles and Permissions to Users ................................................................... 20
3.4. Setting the Default User Level ................................................................................... 21
3.5. Setting the Dashboard Timeout and Refresh Time ......................................................... 21
3.6. Specifying a Default Dashboard Organizer .................................................................. 21
iii
3.7. Creating Object Associations .................................................................................... 21

4. User Groups ..................................................................................................................... 23
6. Email and Pager Settings ............................................................................................................ 26
1. About Email and Pager Settings ........................................................................................... 26
2. Setting SMTP and SNPP Information ................................................................................... 26
7. Organizers and Path Navigation in Zenoss ..................................................................................... 28
1. About Organizers and Path Navigation .................................................................................. 28
2. Classes ............................................................................................................................ 28
2.1. Setting zProperties at the Class Level ......................................................................... 29
2.2. Defining and Applying Templates at the Class Level ..................................................... 30
2.3. Creating New Classes .............................................................................................. 31
3. Systems .......................................................................................................................... 31
3.1. Adding, Moving and Nesting Systems ........................................................................ 31
3.1.1. Moving the Sub-System ................................................................................ 32
4. Groups ............................................................................................................................ 33
4.1. Adding Groups ....................................................................................................... 33
4.1.1. Moving Groups ........................................................................................... 33
5. Locations ........................................................................................................................ 34
5.1. Google Maps Geographic View of Network Health ....................................................... 34
5.1.1. Overview .................................................................................................... 34
5.1.2. API Key ..................................................................................................... 34
5.1.3. Setting an Address for a Location .................................................................... 35
5.1.4. Network Links ............................................................................................. 35
5.1.5. Google Maps Example .................................................................................. 35
5.2. Adding, Moving, and Nesting Locations ..................................................................... 36
5.2.1. Moving Sub-locations ................................................................................... 36
6. Inheritance ....................................................................................................................... 37
7. Multiple Mix-In Inheritance and Performance (RRD) Template Binding ...................................... 38
7.1. Template Binding Example 1 .................................................................................... 38
7.2. Template Binding Example 2 .................................................................................... 38
8. zProperties ............................................................................................................................... 39
1. About zProperties .............................................................................................................. 39
2. Event zProperties .............................................................................................................. 39
3. Device zProperties ............................................................................................................ 39
4. Service zProperties ............................................................................................................ 42
5. Network zProperties .......................................................................................................... 43
6. Manufacturer zProperties .................................................................................................... 43
9. Device Inventory and Configuration ............................................................................................. 44
1. What is Inventory and Configuration in Zenoss? ..................................................................... 44
2. How Does Zenoss Model Devices? ....................................................................................... 44
3. The ZenModeler Daemon ................................................................................................... 44
4. Adding an Individual Device ............................................................................................... 44
5. Add an Individual Device with Context ................................................................................. 46
6. Auto-Discovery of Devices ................................................................................................. 47
7. Device List ...................................................................................................................... 49
7.1. Managing Multiple Devices using the Device List ......................................................... 50
8. Individual Device Tabs ....................................................................................................... 50
8.1. Device Status Tab ................................................................................................... 50
8.1.1. Device Status Tab Example ............................................................................ 51
8.2. OS (Operating Systems) Tab ..................................................................................... 52
8.2.1. File System Monitoring ................................................................................. 53
8.3. Hardware Tab ........................................................................................................ 53
8.4. Software Tab ......................................................................................................... 54
8.5. Events Tab ............................................................................................................ 55
8.6. History Tab ........................................................................................................... 55
8.7. Performance Tab .................................................................................................... 56
8.7.1. Graph Surfing ............................................................................................. 57
8.8. Edit Tab ................................................................................................................ 57
iv
8.9. Custom Tab ........................................................................................................... 58

8.10. zProperties Tab ..................................................................................................... 59
8.11. Templates Tab ...................................................................................................... 60
8.12. Administration Tab ................................................................................................ 61
8.13. Collector Plugins tab ............................................................................................. 61
8.14. Modifications Tab ................................................................................................. 62
9. Searching For a Device By Name or IP Address ...................................................................... 63
10. Editing Device Configurations ........................................................................................... 63
11. Managing Devices ........................................................................................................... 64
11.1. Remodeling a Device ............................................................................................. 64
11.2. Changing the Device Class of a Device ..................................................................... 64
11.3. Resetting Device Manage IP ................................................................................... 64
11.4. Renaming a Device ............................................................................................... 65
11.5. Locking Device Configurations ............................................................................... 65
11.6. Resetting the Device Community ............................................................................. 66
11.7. Pushing Configuration Changes Back to the Zenoss System .......................................... 66
11.8. Clearing Heartbeats ............................................................................................... 66
11.9. Deleting Devices From the System ........................................................................... 67
12. Modeling Devices Using SNMP ......................................................................................... 67
12.1. Testing to See if a Device is Running SNMP .............................................................. 67
12.2. Modeling Remote Windows Devices Using SNMP ...................................................... 67
12.3. Modeling Remote Linux Devices Using SNMP .......................................................... 67
12.4. Modeling Cisco Devices Using SNMP ...................................................................... 68
13. Modeling Using SSH/COMMAND ..................................................................................... 68
13.1. Using Device Class to Monitor Devices Using SSH ..................................................... 68
14. Modeling Devices Using PortScan ...................................................................................... 69
14.1. Using the /Server/Scan Device Class to Monitor with Portscan ...................................... 69
15. Modeling Plugins ............................................................................................................ 69
15.1. Getting a List of Modeling Plugins for a Device .......................................................... 69
16. Debugging the Modeling Process ....................................................................................... 69
17. Using zLinks to Add Custom Links to a Device Status Page .................................................... 70
18. Dumping and Loading Devices Using XML Lists .................................................................. 70
10. Event Monitoring .................................................................................................................... 71
1. About Event Monitoring In Zenoss ....................................................................................... 71
2. Event Concepts ................................................................................................................. 71
2.1. Event Life Cycle .................................................................................................... 71
2.2. De-duplication ....................................................................................................... 71
2.3. Begin-End Correlation ............................................................................................. 72
3. Zenoss Event Console ........................................................................................................ 72
3.1. Viewing Event Details ............................................................................................. 73
4. Generating and Sending a Test Event .................................................................................... 74
4.1. Sending Events from the Command Line .................................................................... 75
5. Event Classes ................................................................................................................... 76
5.1. Creating a New Event Class ...................................................................................... 76
6. Event Manager Settings ...................................................................................................... 76
6.1. Accessing Event Manager Settings ............................................................................. 77
6.2. Changing Event Database Connection Information ........................................................ 77
6.3. Changing Cache Settings for the Event Manager ........................................................... 77
6.4. Change the Maintenance Settings for the Event Manager ................................................ 78
7. Acknowledging Events ....................................................................................................... 78
8. Moving Events To History .................................................................................................. 78
9. Clearing The Event History ................................................................................................. 79
10. Event Class Mapping ....................................................................................................... 79
11. Applying Event and Device Context Using Event zProperties ................................................... 83
12. Mapping Events Through the UI ......................................................................................... 84
13. Using Mappings to Correlate Events ................................................................................... 85
14. Event Commands ............................................................................................................ 86
14.1. Create an Event Command Example ......................................................................... 86
v
14.2. Test the Event Command ........................................................................................ 86

15. SNMP Traps and Event Transforms .................................................................................... 87
15.1. SNMP Trap Mapping ............................................................................................. 87
15.2. Sending Test Traps ................................................................................................ 88
15.3. Transforming Events with Event Mappings ................................................................ 89
15.4. Event Transforms Based on Device Class .................................................................. 90
16. Custom Event Views ........................................................................................................ 90
11. Availability Monitoring ............................................................................................................ 93
1. Monitoring Topology with ZenPing ...................................................................................... 93
1.1. Controlling the Ping Cycle Time ................................................................................ 93
1.2. Using the Predefined /Ping Device Class ..................................................................... 93
2. Monitoring TCP Services ................................................................................................... 93
2.1. Zenstatus .............................................................................................................. 94
2.2. Adding a Service To Monitor .................................................................................... 94
2.3. Monitoring Status Service Status Information .............................................................. 94
2.4. Editing Service Information ...................................................................................... 95
2.5. Configuring Service zProperties ................................................................................ 96
2.6. Using the Predefined /Server/Scan Device Class ........................................................... 96
2.7. Monitoring a Service Using a Service Class ................................................................. 96
3. Monitoring Processes ......................................................................................................... 98
3.1. Adding Processes to Monitor .................................................................................... 98
3.2. Configuring Process zProperties .............................................................................. 100
12. Performance Monitoring ......................................................................................................... 101
1. Performance Monitoring ................................................................................................... 101
2. Performance Templates .................................................................................................... 101
2.1. The Templates Page ............................................................................................... 102
3. Template Binding ............................................................................................................ 102
4. Data Sources .................................................................................................................. 103
5. Data Points .................................................................................................................... 104
6. Thresholds ..................................................................................................................... 105
7. Graph Definitions ............................................................................................................ 106
7.1. Graph Points ........................................................................................................ 107
7.1.1. Data Point Graph Points .............................................................................. 107
7.1.2. Threshold Graph Points ............................................................................... 108
7.1.3. Custom Graph Points .................................................................................. 108
7.2. Custom Graph Definition ....................................................................................... 108
7.3. Graph Commands ................................................................................................. 109
8. Changing the Order of the Graphs ...................................................................................... 109
9. Monitoring A File System and Changing a Threshold ............................................................. 109
13. Monitoring Devices Remotely via SSH ...................................................................................... 111
1. Monitoring Devices Remotely via SSH ................................................................................ 111
1.1. Installing Zenoss Plugins on the Remote Machine ....................................................... 111
1.1.1. Zenoss Plugin Installation Technique: RPM ..................................................... 111
1.1.2. Zenoss Plugin Installation Technique: setuptools .............................................. 111
1.1.3. Testing the Plugin Installation ....................................................................... 112
1.1.4. Troubleshooting the Plugin Installation ........................................................... 112
1.1.5. Changing Zenoss to Monitor the Devices Remotely Using SSH ........................... 112
1.1.6. Using the Predefined /Server/Cmd Device Class ............................................... 114
14. Monitoring Using ZenCommand .............................................................................................. 115
1. About ZenCommands ....................................................................................................... 115
2. Example: Writing a ZenCommand (check_http example) ........................................................ 115
3. Collect Data from A ZenCommand ..................................................................................... 117
4. Plugin Format for ZenCommands ....................................................................................... 117
5. Testing ZenCommands ..................................................................................................... 118
15. Monitoring Windows Devices .................................................................................................. 119
1. Device Preparation for Windows Devices ............................................................................. 119
2. Testing WMI on a Windows Server ..................................................................................... 119
3. Other Optional Windows Configuration Items ....................................................................... 119
vi
4. ZenWin Command Line Parameters .................................................................................... 119

5. Modeling Services on Windows Devices .............................................................................. 120
6. Collecting Windows Eventlog Events .................................................................................. 120
7. Monitoring Windows Performance with SNMP-Informant ...................................................... 121
8. Running Commands on Windows Servers Using Winexe ......................................................... 121
16. SNMP Monitoring ................................................................................................................. 123
1. SNMP from the Command Line ......................................................................................... 123
17. Alerting Rules ....................................................................................................................... 124
1. Creating and Using Alerts ................................................................................................. 124
1.1. Setting SMTP Settings For Alerts ............................................................................. 124
2. Creating a New Alerting Rule ............................................................................................ 125
2.1. Define and Enable This Alert .................................................................................. 127
2.2. 1.1.1 Create the Content of the Alert Message ............................................................ 128
2.3. Create a Schedule for Sending the Alert .................................................................... 129
3. Escalation of Messaging in Zenoss ..................................................................................... 132
3.1. Creating an Alerting Hierarchy ................................................................................ 132
4. Adding Delay and Schedules to Alerting Rules ...................................................................... 132
18. UI Commands ....................................................................................................................... 134
1. About UI Commands ....................................................................................................... 134
2. Defining UI Commands .................................................................................................... 134
2.1. UI Command Example: Echo Command ................................................................... 135
3. Running Commands from the Zenoss Web UI ....................................................................... 136
4. Auto-Running Commands Based on Events .......................................................................... 136
19. Production States and Maintenance Windows .............................................................................. 139
1. About Production States and Maintenance Windows ............................................................... 139
2. Production States ............................................................................................................ 139
2.1. Defining Production States for Devices ..................................................................... 139
3. Maintenance Windows ..................................................................................................... 139
3.1. Creating and Using Maintenance Windows ................................................................ 140
20. Reporting ............................................................................................................................. 142
1. About Reporting in Zenoss ................................................................................................ 142
2. Organizing Reports .......................................................................................................... 143
3. Navigating and Sorting Report Results ................................................................................ 143
4. Exporting Reports ........................................................................................................... 143
4.1. Add An Export Button to a Report ............................................................................ 143
5. Reports Included With Zenoss ............................................................................................ 144
5.1. Device Reports ..................................................................................................... 144
5.2. Event Reports ...................................................................................................... 145
5.3. Performance Reports ............................................................................................. 145
5.4. User Reports ........................................................................................................ 146
6. Graph Reports ................................................................................................................ 146
6.1. Creating a New Graph Report .................................................................................. 146
6.2. Adding Graphs ..................................................................................................... 147
6.3. Customizing Graph Text ......................................................................................... 148
6.4. Organizing Graphs ................................................................................................ 149
7. MultiGraph Reports ......................................................................................................... 149
7.1. Creating A New MultiGraph Report ......................................................................... 150
7.2. Collections .......................................................................................................... 151
7.3. Graph Definitions ................................................................................................. 152
7.4. Graph Groups ...................................................................................................... 153
7.5. Graph Order ........................................................................................................ 154
8. Creating Custom Reports .................................................................................................. 154
8.1. Creating Custom Reports Using the ZMI ................................................................... 154
8.2. Create A Custom Device Report Example .................................................................. 154
9. Using Reports to Help Troubleshoot Zenoss Daemons ............................................................ 156
21. General Zenoss Administration ................................................................................................. 157
1. Working with Zenoss from the Command Line ...................................................................... 157
2. Minimal Zenoss - ZEO and Zope ........................................................................................ 157
vii
3. Checking the Version of Zenoss .......................................................................................... 157

4. Checking for Zenoss Updates ............................................................................................ 158
5. Starting and Stopping the Zenoss Daemons .......................................................................... 158
6. Zenoss Daemon Commands and Options ............................................................................. 158
6.1. Configuring Zenoss Daemons ................................................................................. 159
6.2. General Options for All Daemons ............................................................................ 159
6.3. zenhub Options .................................................................................................... 159
6.4. zenmodeler Options .............................................................................................. 159
6.5. zenperfsnmp Options ............................................................................................. 160
6.6. zenperfxmlrpc Options ........................................................................................... 160
6.7. zenProcess Options ............................................................................................... 161
6.8. zenping Options ................................................................................................... 161
6.9. zensyslog Options ................................................................................................. 161
6.10. zenstatus Options ................................................................................................ 161
6.11. zenactions Options .............................................................................................. 162
6.12. zentrap Options ................................................................................................... 162
6.13. zencommand Options ........................................................................................... 162
7. Troubleshooting Zenoss Daemons ...................................................................................... 162
8. Automatic Startup in Linux Environments ............................................................................ 163
9. Using Zenoss with a Remote MySQL Instance ...................................................................... 163
10. Registering MIBs with Zenoss ......................................................................................... 163
10.1. Resolving MIB Dependencies ................................................................................ 164
22. Backup, Recovery and Maintenance .......................................................................................... 165
1. Backup and Restore ......................................................................................................... 165
1.1. Backup Details ..................................................................................................... 165
1.2. Restore Details ..................................................................................................... 166
1.3. Periodic Backups .................................................................................................. 167
1.3.1. Pack ZEO Database .................................................................................... 167
1.3.2. Log Rotate Script ....................................................................................... 167
1.3.3. Backing up the MySQL Event Backend .......................................................... 167
23. ZenPacks ............................................................................................................................. 168
1. About Zenpacks .............................................................................................................. 168
1.1. Installing ZenPacks ............................................................................................... 168
1.2. Creating a ZenPack ............................................................................................... 168
1.3. Example ZenPack ................................................................................................. 168
1.4. ZenPack Structure ................................................................................................. 168
1.4.1. HelloWorldZenPack/ ................................................................................... 168
1.4.2. HelloWorldZenPack/init.py .......................................................................... 169
1.4.3. HelloWorldZenPack/HelloWorld.py ............................................................... 169
1.4.4. HelloWorldZenPack/daemons ....................................................................... 169
1.4.5. HelloWorldZenPack/datasources ................................................................... 169
1.4.6. HelloWorldZenPack/modeler ........................................................................ 169
1.4.7. HelloWorldZenPack/objects ......................................................................... 169
1.4.8. HelloWorldZenPack/skins ............................................................................ 169
1.5. Removing a ZenPack ............................................................................................. 169
2. ZenJMX ........................................................................................................................ 169
2.1. About ZenJMX ..................................................................................................... 169
2.2. JMX Background .................................................................................................. 170
2.3. ZenJMX Capabilities ............................................................................................. 170
2.4. Single Value Attribute Calls .................................................................................... 170
2.5. Multi-Value Attribute Calls ..................................................................................... 171
2.6. Operation Calls .................................................................................................... 171
2.6.1. Operation Calls: Scenario #1-No parameters, single return value ......................... 172
2.6.2. Operation Calls: Scenario #2-No parameters, multiple values returned in List
format .............................................................................................................. 172
2.6.3. Operation Calls: Scenario #3-No parameters, multiple values returned in Map
format .............................................................................................................. 172
2.6.4. Operation Calls: Scenario #4-Single parameter in polymorphic operation .............. 173
viii
2.6.5. Scenario #5: Multiple parameters in polymorphic operations .............................. 173

2.7. ZenJMX Behavior ................................................................................................. 174
2.8. Running the ZenJMX Daemon ................................................................................ 175
2.9. Defining Custom JMX Data Sources ........................................................................ 175
2.10. Enabling Remote JMX Access ............................................................................... 176
2.10.1. Remote JMX Access for the standard JVM .................................................... 176
2.10.2. Remote JMX Access for Tomcat .................................................................. 176
2.10.3. Remote JMX Access for JBoss .................................................................... 176
2.10.4. Remote JMX Access for WebLogic .............................................................. 177
2.11. Interrogating an JMX Agent via JConsole ................................................................ 177
2.12. Installing ZenJMX .............................................................................................. 181
2.12.1. Installing ZenJMX on an appliance .............................................................. 181
A. Net-SNMP and Zenoss ............................................................................................................ 182
1. Net-SNMP Configuration Settings ...................................................................................... 182
1.1. Community Information ......................................................................................... 182
1.2. System Contact Information .................................................................................... 182
1.3. Extra Information ................................................................................................. 182
B. Event Database Dictionary ........................................................................................................ 183
1. Event Database Dictionary ................................................................................................ 183
C. TALES Expressions ................................................................................................................ 184
1. About TALES Expressions ................................................................................................ 184
2. TALES Device Attributes .................................................................................................. 184
3. TALES Event Attributes ................................................................................................... 186
D. Device Preparation .................................................................................................................. 187
1. Net-SNMP ..................................................................................................................... 187
2. Forwarding Syslog messages from UNIX/Linux Devices ........................................................ 187
3. Forwarding Syslog Messages from a Cisco IOS Router ........................................................... 187
3.1. Other Cisco syslog Configurations ........................................................................... 187
4. Forwarding Syslog Messages from a Cisco CatOS Switch ....................................................... 188
5. Forwarding Syslog Messages using Syslog-ng ...................................................................... 188
E. Zenoss Licensing Information ................................................................................................... 190
1. ZENOSS CORE (TM) END USER LICENSE AGREEMENT ................................................. 190
2. GNU General Public License ............................................................................................. 192
ix
Chapter 1. Introduction
1. Zenoss Overview
The Zenoss system brings together many types of monitoring and management information. The information is
available through a standard web browser. In fact all aspects of the system are accessed though the web there is
no need to edit configuration files. At a high level, Zenoss consists of four major parts:
Figure 1.1. Zenoss High-Level Architecture
1.1. The Zenoss Standard Model

At the core of Zenoss is the Standard Model. The model is a detailed description of any device Zenoss manages
and that device's relationship to your other devices, business units or any other important groupings you define.
Because of the high degree of detailed information in the model, there are several ways the model's information
is populated. The primary way information is added to the model is is through a process Zenoss calls "auto-discov-
ery". Auto-discovery is defined as Zenoss using one of the available transports to discover the services, interfaces
etc on a device. From this information, Zenoss builds a model of the device in the system. The model can also be
populated by adding and manipulating data associated with the device though the web UI (or through Zenoss' ex-
ternal APIs). Version 2.0 adds discovery locking which allows auto-discovered information to be tightly integrated
with manually added information. The model is used to drive all monitoring elements of the Zenoss system which
will be described throughout the rest of this document.
1.2. Availability Monitoring in Zenoss

Availability monitoring in Zenoss consists of the system running tests against the IT infrastructure to determine
if it is currently functioning properly. These tests are typically run external to the monitored system. Examples
tests include: ping tests, process tests, and service tests.
1
Introduction
1.3. Zenoss Event Management System

The Zenoss Event Management System is a consolidation of status information from all parts of the Zenoss system
as well as any monitored external systems. When a Zenoss monitoring daemon detects a failure or threshold breach,
events are generated. This is similar to most other monitoring systems available. Zenoss does more in that it also
incorporates event imports from other parts of the IT infrastructure. These include Syslog and SNMP Traps. It is
one thing to bring the events into a single repository but an event management system must do more. As events
are received, Zenoss runs them through a set of rules that augment the information contained therein and integrates
all of this information into the Zenoss Model.
1.4. Zenoss Performance Monitoring System

The Zenoss Performance Management System tracks important IT resource information and tracks these changes
over time. It is critical to know how much disk space is available, what the CPU load is, or how long a web page
takes to download. Zenoss can collect information using SNMP, custom scripts (ZenCommands) or XML-RPC.
Performance information is integrated with the Zenoss Model so that resource usage is shown in the context of
other Zenoss information.
2
Chapter 2. Detailed Architecture
1. Zenoss Detailed Architecture
The following diagram shows a more detailed view of the architecture of the Zenoss system.
Figure 2.1. Zenioss Detailed Architecture
The diagram shows the 3 distinct layers of the Zenoss system: The User Layer, the Data layer, and the Collection
and Control Layer where the Zenoss Daemons reside and perform their duties.
2. User Layer
The User Layer is manifested as a Web Console/Portal. This layer consists of the Graphical User Interface (GUI),
which allows the user access to the following pieces of information:
Dashboard Events Locations

Devices Manufacturers Reports
Services Systems Users
Networks Groups Administration
3
Detailed Architecture
The User Layer Interacts with the Data layer and translates the information for display in the GUI.
3. Data Layer
The Data Layer is where all of the system information is stored. This layer consists of the Zenoss Daemons as well
as zeoctl and zopectl to run the heart of the system. Zeoctl is the back-end object database that stores the configur-
ation model, and zopectl controls the zope web application development environment used to display the console.
Daemon Description
ZenrRRD ZenRRD gathers Time Series Data and acts as an
RRDtool.
Zenevents Zenevents interacts with the MySQL Events Database.
Zenmodel Zenmodel Is the United Configuration Model of the Zope
object database.
Zenhub Broker of information between the data layer and the
collection daemons.
4. Collection and Control Services Layer

The services that collect the data and feed it to the Data Layer come from the daemons associated with the Collection
and Control Services Layer. These daemons can be broken down into five distinct areas: Automated Modeling,
Availability Monitoring, Event Collection, Performance Monitoring, or Automated Response. The daemons that
fall under each layer are detailed below.
4.1. Automated Modeling Daemons

Daemon Description
Zendisc Zendisc is a subclass of zenmodeler and it goes out to
discover new network resources. It walks the routing
table to discover the network topology and then pings
all discovered networks to find active IPs and devices.
ZenwinModeler ZenWinModeler is used for the auto-discovery of Win-
dows Services (WMI) running on a windows box.
ZenModeler ZenModeler is a configuration collection and configura-
tion daemon. It is used for high-performance, automated
model population using SNMP, SSH, and Telnet to col-
lect its information. Zenmodeler works against devices
that have been loaded into the DMD.
4.2. Availability Modeling Daemons

Daemon Description
Zenping Zenping is the ping status monitoring (ICMP) for Zenoss.
Zenping does the high-performance asynchronous testing
of the ICMP status.
Zenwin Zenwin is used for Windows Service Monitoring (WMI).
Zenstatus Zenstatus performs active TCP connection testing of re-
mote daemons.
Zenprocess Zenprocess enables process monitoring using SNMP
host resources mib.
4
Detailed Architecture
4.3. Event Collection Daemons

Daemon Description
Zensyslog Zensyslog is collection of and classification of syslog
events.
Zeneventlog Zeneventlog is used collect (WMI) event log events.
Zentrap Zentrap collects SNMP Traps. It receives traps and turns
them into events.
4.4. Performance Monitoring Daemons

Daemon Description
ZenperfSNMP ZenperfSNMP does the high performance asynchronous
SNMP performance collection.
ZenperfXMLrpc ZenperfXMLrpc is used for XML RPC Collection.
Zencommand Zencommand is used for XML RPC Collection specific-
ally it allows the running of Nagios© and Cactii plug-
ins on the local box or on remote boxes through SSH.
4.5. Automated Response Daemons

Daemon Description
Zenactions Zenactions is used for alerts (SMTP, SNPP and Mainten-
ance Windows).
5
Chapter 3. Key Concepts
1. Classification
Many of Zenoss’s hierarchies are used to classify IT entities, things like Devices (computers, routers, switches,
etc) or Events (status information sent out by devices). Once an item is properly classified the system understands
more about the item. This makes proper classification an important activity in the system. Often classification
happens automatically with the ability for manual override later.
2. zProperties
Zenoss allows configuration to be specified using its hierarchical organization system. zProperties are properties
applied to devices or groupings that help maintain more specific control in different modules of Zenoss. zProperties
can be set at any level of a hierarchy, and values set at lower levels of the hierarchy override those above.
3. Inheritance and Path Navigation

Zenoss uses hierarchies much like a file system does to organize information. These hierarchies are navigated using
paths just like a UNIX file system or a web URL. The paths are navigating objects in a database though, and not
an actual file system.
6
Chapter 4. Zenoss Interface and
Navigation
1. Zenoss Dashboard
Once you have installed Zenoss and entered the URL for the UI, the Zenoss Dashboard appears. The Dashboard
is the primary window into the devices, events and activities within the Zenoss system. The Dashboard shows
Systems-level event summaries, devices that currently have events with severity of at least “Error” magnitude,
and infrastructure issues along with a navigational bar. There is a search field, where you can enter a machine’s
name or partial name or IP address. All or some of a machine's name may be typed in to search for it, as well as
an IP address. User information may be accessed through the “Preferences” link in the top right of the screen.
Below the Preferences link is the time and date that Zenoss was last updated. Every 60 seconds there is an AJAX
call that refreshes the data fields and polls for new data. If the poll fails, it will display “Lost Connection to Zenoss”
near the User information area.
Figure 4.1. Zenoss Dashboard
2. Left Navigation Menu

The Left Navigation menu consists of the three main sections: the Main Views, Classes, Browse By, and a Man-
agement Section.
Hiding the Left Navigation Menu
7
Zenoss Interface and Navigation
You can use the triangle above the left navigation menu to hide the menu, and then you can use the pin icon to
“pin” the menu into place and the left navigation menu will remain visible.
2.1. Main Views

The Main Views section of the Navigational Bar consists of the following views: The Dashboard, which returns
you to the main view; The Event Console, which will show a list of all of the current events in the Event Database;
The Device List, which shows you a list of all of the devices in the Zenoss system; and the Network Map link
which shows you a graphical representation of the devices in your network.
2.2. Classes
The Classes area contains the following links: The Events link will take you to the event management tabs where
you can monitor event status, events, history, zProperties, event transforms and also track any changes made to
events. The Devices link allows you to manage sub-devices and a summary of events by severity. You can also
look at events sorted by severity followed by device name, history of device events, PerfConfig, zProperties for
Devices, and recent changes made to the Devices. The Services link allows you show service Classes, administer
commands on a Service basis and also access zProperties and track any changes made to Services monitoring.
Processes Classes allows you to create new process groupings )here called Sub-folders) and also add processes to
monitor. You can also set a Sequence or order in which to gather process monitoring information. You can also
use the Process Class to run commands against processes, or access process zProperties. The Products link will
show you a list of all the manufacturers of devices in the Zenoss database.
2.3. Browse By
Use the "Browse by" areas to see data based on any of the logical groupings Zenoss allows you to create. Either
"Systems", a more generic "Groups", the physical location-related "Locations", a networking based "Networks",
or you can see and define "Reports". Browsing by Systems allows you to see network statuses broken down into
the system groupings you have created. Show performance data based on these systems and also see Events and
the Event history for these systems. You can also Use the Administration tab to define commands, create maintenance
windows or define administered objects on a Systems basis. Browsing by Groups allows you access to the same
kind of data accessed when Browsing by System (only here on a "Group" basis) with the notable exception of
tracking Performance data on a Group basis. Browsing by Locations refer to seeing data related to devices grouped
by physical locations. Here devices can only be in one location but multiple nested sub-locations. A device can
reside in several Groups in the groupings area, but should only reside in one physical location at a given level of
a hierarchy. Nesting in sub-locations is perfectly acceptable, though. For example, a device can reside in the Loc-
ation "Maryland", and also in sub-location Annapolis, but not simultaneously in the sub-location "Bethesda". Even
though both are sub-locations you can define under "Maryland". You can also see a cool Google-based map of the
physical locations of your devices and see status that way. Browsing by Networks, will show you the devices and
sub-networks, based on IP address groupings. You can also see and access zProperties based on IP address
groupings and see any changes made to any Networks. The Reports option allows you to see and define the Reports
available within the Zenoss system.
2.3.1. Management
Add Device
Mibs - Add New organizer, Add new MIBS
Monitors - Status Monitors and Performance Monitors
Settings - Settings, commands users ZenPacks Menus Daemons Versions
Event Manager - EDIT connection information, cache, maintenance, FIELDS - connection information, history
fields, COMMANDS - commands triggered by events
8
2.4. Hiding the Left Navigation Menu

You can use the triangle above the left navigation menu to hide the menu, and then you can use the pin icon to
“pin” the menu into place and the left navigation menu will remain visible.
3. Directory Path
The directory path is where the path on the machine is displayed showing the current location of the data appearing
in the UI.
4. Device/IP Search Box

You can use the Search box to find any device using its name (or partial name) or IP address.
5. User Information Area

The ID of the current user is shown in the top right of the screen just to the left of the Preferences link. You can
also access user setting by clicking the Settings link in the left navigation area.in the link or log out using the Log
Out link.
6. Customizing Zenoss Dashboard Portlets

You can customize the Zenoss Dashboard by selecting and arranging various portlets that display different inform-
ation about the system. You can also arrange how the portlets appear on the screen.
To set the arrangement of the portlets on the dashboard, from the top right hand side of the Dashboard, select
Configure layout. The Column Layout dialog appears.
Figure 4.2. Column Layout Dialog
Select the column layout for your dashboard. Once you have selected the column layout, you can then drag and
drop the portlets wherever you want on those grids.
To select which portlets you want to see on the dashboard: From the Zenoss Dashboard, in the top right, select
Add Portlet. The Add Portlet dialog appears.
9
Figure 4.3. Add Portlet Dialog
Select the portlets you want to appear on the dashboard from the list. Available portlets include:
• Device issues
• Top level Organizers
• Watch List
• Google Maps
• Zenoss Issues
• Production States
6.1. Devices Issues Portlet

This section displays the name of the device, the acknowledged status, and amount of Critical and Error severity
level events. “Devices” can be clicked on to take you to the Devices event log, which is default sorted by severity.
Clicking on the specific device will take you to the device log of that device. The events are shown in fractions of
acknowledged/total. If they are acknowledged it shows the user that acknowledged it.
Figure 4.4. Device Issues Portlet
6.1.1. Configuring the Device Issues Portlet

To configure the information that appears in the Device Issues Portlet click the asterisk in the top right of the
portlet window. A drop down configuration dialog appears where you can change the information for this portlet.
You can change the Title of the portlet or the Refresh Rate. This is also how you remove the portlet from the
Dashboard.
10
Figure 4.5. Device Issues Portlet Configuration
6.2. Top Level Organizers

The Top Level Organizers portlet shows all of the organizers at the top level of the hierarchy so you can see summary
events for each organizer.
Figure 4.6. Top Level Organizer Portlet
6.2.1. Configuring the Top Level Organizer Portlet

To configure the information that appears in the Top Level Organizer Portlet click the asterisk in the top right of
the portlet window. A drop down configuration dialog appears where you can change the information for this
portlet. You can change the Title of the portlet or the Refresh Rate, and also choose which Root Organizer you
want to display. This is also how you remove the portlet from the Dashboard.
Figure 4.7. Top Level Organizer Configuration
11
6.3. Watch List Portlet

The Watch List Portlet shows a Device Watch List you can configure a list of watch devices an also the refresh
rate for the gathering data for devices in the list.
Figure 4.8. Watch List Portlet
6.3.1. Configuring the Watch List Portal

Dashboard. You can also add or remove devices from the Watch List here.
Figure 4.9. Watch List Portlet Configuration
6.4. Google Maps Portlet

The Google Maps Portlet allows you to see the Location map with Location you have set up and network connection
statuses. Here is a look at the Google Maps portlet.
Figure 4.10. Google Maps Portlet
6.4.1. Configuring the Google Maps Portlet

12
Dashboard. You can also set the Base Location here.
Figure 4.11. Configuring the Google Maps Portlet
6.5. Zenoss Issues Portlet

Zenoss Infrastructure Issues will show any problems with a Zenoss daemon. Heartbeats statuses of the Zenoss
daemons appear here when there is a problem. If an issue appears in this list, it could be that the daemon is not
running.
Figure 4.12. Zenoss Issues Portlet
6.5.1. Configuring the Zenoss Issues Portlet

Dashboard.
13
Figure 4.13. Configuring the Zenoss Issue Portlet
6.6. Production States Portlet

The Production States Portal allows you to see all of the devices in a given Production State.
Figure 4.14. Production State Portlet
6.6.1. Configuring the Production States Portlet

Dashboard. You can also choose what Production States you want to appear on the Dashboard here.
Figure 4.15. Configuring the Production State Portlet
14
7. Zenoss Network Map

The Network Map is a Flash representation of your network's layer 3 topology. You can see the status of the devices
on your network by noting the background color of the devices. You can select a particular device or network by
double clicking on its icon in the map. This will center the map on the device or network and show the links from
this node based on the number of hops selected. The same result is achieved by typing the name of the device or
network and clicking the "Refresh" button. Note that when you select a node what is actually displayed are the
links that are currently loaded into the map it does not download new link data at that time.
To load/reload the link data for a particular node, double click on that node, select the number of hops and click
the refresh button. You can also filter the devices shown by Device Class. For example, to show only Linux devices,
select /Server/Linux in the Device Class Filter and click refresh.
You can also adjust the number of viewable hops from the selected device by using the Number of Hops slider in
the top right corner. You can also spread out the icons on the map by using the Repulsion slider also in the top
right corner. If you'd like to get more detail on the selected device or network, just click the Go to Status Page link
in the top left corner.
Figure 4.16. Zenoss Network Map
8. "Menu-ized" Elements
Zenoss now has two different kinds of menus where some elements that previously resided on pages are now located.
15
8.1. Page Menus

Page menus extend the tabs near the top of the page and usually affect the entire object that the page represents.
This could be a device, event or any grouping of these elements. In the following figure you can see the Page menu
expanded next to the Classes tab.
Figure 4.17. Page Menu
8.2. Table Menus

Table menus are accessed by clicking the triangle next to a table title inside a particular page. The following figure,
which is the same page as above, shows the Table menu expanded. In this case it is the Sub-Devices table menu.
16
Figure 4.18. Sub-Devices Table Menu
17
Chapter 5. User Management
1. About Zenoss User Accounts
Each user should have a unique User ID. These User IDs group permissions and alerting rules together as well as
providing security to the Zenoss system. To create and manage user accounts in Zenoss, you must be logged into
the Zenoss Admin account, or logged in to a created user account with manage privileges. Custom Event Views
and Alerting Rules are also defined per user. Those items are discussed in other areas of this documentation.
2. Creating New User Accounts

To create a new user account:
1. From the menu on the left side of the Zenoss Dashboard, select Zenoss Settings.
2. Click the Users Tab. The Users Administration page appears.
Figure 5.1. User Administration page
3. Click the User Folder table menu to show the User Options.
Available options will be Add User, Delete User and Add to ZenPack
4. Select Add User.
The Add User dialog appears.
18
User Management
Figure 5.2. Add User Dialog
5. Enter a name for the account in the Username field.
6. Enter an Email address for the user account.
This is the address where any alerts you set up for this user will be sent.
7. Click the OK button.
The user appears in the User List.
You have now created a new user account. You must still edit the User account to provide a password and ad-
ditional User details. See the Editing Users section in the Users Guide section for information on setting User
preferences.
3. Editing User Accounts

1. From the menu on the left side of the Zenoss Dashboard, select Settings.
2. Click the Users Tab.
The Users Administration page appears.
3. Click the name of the user account you want to edit.
The individual User Administration page for the newly created user appears.
19
User Management
Figure 5.3. Individual User Administration Page
4. Make the changes as detailed in the sub sections below and click the Save button to keep the changes.
3.1. Setting User Passwords

From the Individual User Administration page, assign a password for the user. Enter it again to confirm it in the
next text box.
3.2. Editing User Contact Information

From the Individual User Administration page, you can enter and edit the email address and/or pager number.
3.3. Assigning Roles and Permissions to Users

From the Individual User Administration page, you can assign specific roles for each user privileges for this User.
These roles are roles available to be set by the one Zenoss Admin user. If you have manger role set, then you can
change settings for your own account or for any other accounts as well (including other manager accounts).
20
User Management
Table 5.1. Zenoss User Roles

Role Privileges
Manager The Manager role has full privileges. This role has
viewing and editing privileges on objects in the system.
Managers also see the Management area of the Naviga-
tion menu on the left side of the web console. These op-
tions include: Adding Devices, User management for all
users (including changing roles), Monitors, Live Event
viewing, History Events and also the About information.
ZenUser ZenUser has viewing information of all the information
in the system., Users with the role ZenUser can also edit
their own user information (except for changing their
Role). ZenUsers cannot add devices and do not see the
Management section of the Navigation menu on the left
side of the web console.
3.4. Setting the Default User Level

The Default User Admin Level sets the default role for administered objects. This default is easily changed, but
you should choose the role here that is most commonly added. Choose between the following roles to set as the
default.
• Administrator
• Engineer
• Analyst
• Tester
These User admin levels are currently merely ways to categorize and group users. In the future there may be more
attributes that would be assignable per group/role. For now it is just a way to categorize and classify users.
3.5. Setting the Dashboard Timeout and Refresh Time

You can change the Dashboard Settings such as timeout and Refresh times on a per user basis. In the Dashboard
Refresh and Dashboard Timeout fields, enter the number of seconds before a timeout message appears for the
Zenoss Dashboard.
3.6. Specifying a Default Dashboard Organizer

The default Dashboard organizer is is what appears in the Devices Summary on the Dashboard for this particular
user. You can change your view to group as either Devices, Systems, Groups, or Locations.
3.7. Creating Object Associations

You can associate any object in the Zenoss system with a particular user (for monitoring or reporting purposes).
To create these associations:
1. From the Individual User Administration page, click the Administered Objects tab.
The Administered Object Tab appears.
21
User Management
Figure 5.4. Administered Objects Initial View
2. Select an object type from the Administered Devices table menu. You can choose between adding a Device,
System, Group, or Location.
A dialog will appears where you can specify the component you want to add as an administered object.
3. Click the OK Button.
The Device appears in the Administered Devices list for this user.
22
User Management
Figure 5.5. Administered Object - Object Added
4. You can now change the role that is associated for this user on this object.
The default role is set in the Individual User Administration Page.
You can also set administered objects from the device you want to add as an administered object. For example,
navigate to the device you want to add to this user’s administered objects page. Open the page menu for this
device, select More and then the Administration option. Open the Administrator's table menu choose Add Ad-
ministrator and select the user you want to add as an administrator. The object is added to the user’s administered
object list, and the name appears in this object’s Administrator’s List.
4. User Groups
You can create Zenoss User groups to aggregate rules and apply them across multiple user accounts. To create a
new User Group:
1. From the Left Navigation menu, select Settings.
2. Click the Users tab.
The Users tab appears.
23
User Management
Figure 5.6. Users Tab showing User Groups
3. From the Groups table menu, select Add New Group.
The Add New Group dialog appears.
Figure 5.7. Add New User Group Dialog
4. In the Group field, enter a name for this user group.
The name of the group you entered appears in the Groups list.
6. Click the name of the Group you just created.
The Edit tab for this group appears.
7. From the Users In Group Table menu, select Add User.
The Add User to Group dialog appears.
24
User Management
Figure 5.8. Add User to Group Dialog
8. From the User drop-down, select the users you want to add to the group.
The user(s) you have selected appear in the list of users for this group.
You can also choose administered objects and Alerting Rules for this User group. These Alerting Rules will apply
to all users in the group. The User's original Alerting Rules and objects will also apply.
25
Chapter 6. Email and Pager Settings
1. About Email and Pager Settings
Zenoss alerts can be sent to users via email (SMTP) or pager (SNPP.) Many operating systems include an SMTP
server (such as Sendmail or Postfix) with their distributions. If your OS does not include a mail server you will
need to install one or specify a separate SMTP server in the settings. Many pagers can accept messages via email,
but Zenoss also provides the option of sending pages via SNPP if you specify an SNPP server in the settings.
2. Setting SMTP and SNPP Information

To edit Zenoss's SMTP and SNPP settings make sure you are logged into a Zenoss manager account and click on
Settings in the left navigation menu.
1. While logged in to a user account with management privleges, from the left navigation menu, click Settings.
The Settings Tab appears.
Figure 6.1. Zenoss Settings- Settings Tab
2. Change the following SMTP Settings as necessary:
26
Email and Pager Settings
Table 6.1. SMTP Options

Field Description
SMTP Host Set the SMTP Host to your corporate email server. If
you were a Zenoss employee for example your corpor-
ate email server would be mail.zenoss.com.
SMTP Port Usually Port 25.
SMTP Username leave this field blank for none
SMTP Password leave this field blank for none
From Address for Emails Use if you want the emails to come from a specific
email address.
Use TLS?
SNPP Host Use if you want the emails to come from a specific
email address.
SNPP Port Port for pager sever (usually 444)
27
Chapter 7. Organizers and Path
Navigation in Zenoss
1. About Organizers and Path Navigation
Zenoss allows you to group any objects in the system (devices, subsystems, zProperties, templates, etc.) The
groupings can be created in any way that you desire or define. There are also device classes that are tied to events
coming into the system and inheritance works the same for any of these groupings. So each device can belong to
several different groupings including groups, systems, locations and device classes. In the example below, you
can see the device tilde.zenoss.loc belongs to 5 different classifications. Any zProperties and monitoring settings
for each of these groups are now applied to to tilde.
Figure 7.1. Device Groupings
Zenoss uses several organizers to classify and organize devices in the system.
• Class - the most important organizer - templates and zproperties are inherited through this hierarchy
• Systems
• Groups
• Locations
2. Classes
The most important organizer within Zenoss is Class. There are Device Classes, Event Classes, Service Classes,
and Product Classes. Templates and zProperties are can both be inherited based on Class. These attributes can be
overwritten further down the class hierarchy all the way down to the individual component level. The Class hierarchy
includes all defined and standard Classes and Sub-classes.
The following examples use Device Classes and Sub-classes, but the same concepts apply to Event Classes, Service
Classes, and Product Classes. When you add a new device to Zenoss, you should (after providing the network
name or IP address), at a minimum, specify its device class. Templates and zProperties can be set at any level in
the Device Class hierarchy.
To see all of the device in Device Class:
28
Organizers and Path Navigation in
Zenoss
1. From the left navigation menu, select Devices.
The Device Classes tab appears. Notice that the navigation path above the tab has changed to '/Devices'. Thats
how you know where you are in the class hierarchy.
Figure 7.2. Device Class Tab
The Device Class tab shows an event rainbow for that class level and a Summary for the next level of class hierarchy
with an indicator of whether or not there any devices in any of the classes that have events associated with them.
2.1. Setting zProperties at the Class Level

To set zProperties at the Device Class Level:
1. Navigate to the Device Class tab for the class you where you want to set zProperties, and click the zProperties
Tab.
The zProperties tab for this Device Class appears.
29
Zenoss
Figure 7.3. Device Class zProperties tab
2. Now you can define any of the normal Device zProperties and these will apply to all devices in this class or
added to this class unless over-ridden at a lower level in the hierarchy.
2.2. Defining and Applying Templates at the Class Level

To define Templates at the Device Class Level:
1. Navigate to the Device Class tab for the class you where you want to set Templates, and click the Templates
Tab.
The Templates tab for this Device Class appears.
30
Zenoss
Figure 7.4. Device Class Template tab
2. Now you can define or bind any Device Template and they will apply to all devices in the class or added to this
class unless over-ridden at a lower level in the hierarchy.
2.3. Creating New Classes

To create a new Device Class:
From the Class level where you want to add the organizer, navigate to the Classes tab.
From the SubClasses Table menu, select Add New Organizer and then enter a name for the organizer.
To add devices to this device class you can navigate to the Device List, select the Devices you want to add to the
class and from the table menu, select Move to Class and choose which class you want to move the devices to.
3. Systems
Systems are intended to follow virtual setups like you would have in a network setup or systems grouped by
functionality.
3.1. Adding, Moving and Nesting Systems

To create a new System or Sub-System:
1. From the Navigation menu on the left, under Browse by, select Systems.
The Sub-systems Status tab appears.
31
Zenoss
Figure 7.5. Sub-systems Status Menu
2. Open the Sub-Systems table menu and select the Add New Organizer option. The Add Organizer dialog appears.
Figure 7.6. Add Organizer Dialog
3. In the ID field, Enter the name for the new Sub-system.
4. Click OK.
The new sub-system is added and appears in the list.
3.1.1. Moving the Sub-System

To move the sub-system into another group or sub-group:
1. Select the system from the system list by clicking the check box next to the systems that you want to move and
then open the Sub-Systems table menu to show the Subsystem options.
2. Select the Move Organizer option. The Move Organizer dialog appears:
32
Zenoss
Figure 7.7. Move Organizer Dialog
3. From the pop-up menu, select where you want to move this system.
4. Click Move.
The system is moved to the selected system and the attributes page for the system where you moved the system
appears.
4. Groups
Using Groups is much like using systems only the intent is to use groups as functional divisions or even monitoring
organizers to assign attributes to multiple objects with similar function or even among departmental lines. Note
that groups do not appear on the Dashboard. Even though they do not appear on the dashboard, they still help to
create additional organizers for monitoring or alerting.
4.1. Adding Groups

1. From the Navigation menu on the left, under Browse by, select Groups.
2. From the Settings tab, open the Sub-Groups table menu.
3. Select the Add New Organizer option.
The Add Organizer dialog appears.
4. In the ID field, Enter the name for the new Sub-Group.
5. Click OK. The new sub-group is added and appears in the list.
4.1.1. Moving Groups

To move the sub-group into another group or sub-group:
33
Zenoss
1. Select the group from the group list by clicking the check box next to the groups that you want to move and
then open the Sub-Groups table menu to show the group options.
2. 1.Select the Move Organizer option.
The Move Organizer dialog appears.
Figure 7.9. Move Organizer
3. From the pop-up menu, select where you want to move this group.
4. Click Move.
The group is moved to the selected group and the attributes page for the group where you moved the group
appear.
5. Locations
Using Locations is much like using systems and groups only the intent is to use locations as logical groupings for
physical locations of systems. They can be as general as city and state or as specific as rack or closet. It is completely
customize-able. Note that locations also do not appear on the Dashboard. Even though they do not appear on the
dashboard, they still help to create additional organizers for monitoring or alerting.
5.1. Google Maps Geographic View of Network Health

5.1.1. Overview
Zenoss can map Locations using a Google Maps mashup feature by setting the Location's "Address" property to
an address that Google Maps considers valid.The selected Location will appear on the map as a dot. The color of
the dot represents the highest severity of any event on any device under that Location. In addition, network con-
nections that span Locations will be represented on the map by lines also color-coordinated to the appropriate to
the status of that connection.
To access the Google Map of a network Location, from the left navigation menu, click Locations, select the Loc-
ation want to see the network map, and click the Map tab. The Network map is also one of the portlets you can
add to the dashboard.
5.1.2. API Key

Before you can use the Google Maps feature, you must register for a Google Maps API key. Free Google Maps
API keys are linked to a base URL by which an application must be accessed for Google Maps to function. Enterprise
customers do not have this limitation.
To obtain a free Google Maps API key:
1. Point your browser to: http://www.google.com/apis/maps/signup.html
34
Zenoss
2. Fill in the URL by which you access your Zenoss web interface. Include the port. For example, "http://local-
host:8080".
Users accessing the Zenoss web interface via a different URL than the one you specify here (for example, by
IP instead of hostname) will not be able to use the Google Maps feature.
3. Agree to the terms and click OK to receive your API key. Copy it to the clipboard.
5.1.3. Setting an Address for a Location

1. From the left navigation menu, select Locations.
2. From the Summary table, next to Address, click Edit.
An Edit dialog slides down.
3. In the New Address field, enter a complete address that can, be resolved by Google Maps (if you're unsure,
head to http://maps.google.com and see if it maps).
4. Click the Save button.
You have now created the adress for the loation that will appear on the map for this location. You must add
devices (at least one) to the Location for the dot to appear on the map.
5.1.4. Network Links

If two devices in the same network are in different mappable Locations, a line will be drawn on the map representing
a network connection between the two. If there are multiple separate network connections between the same two
Locations, only one line will be drawn. The color of the line will represent the highest severity of any events af-
fecting the connection. These are determined by:
• A ping down event on the device at either end of the connection; or
• Any event on the interface at either end of the connection.
5.1.4.1. zDrawMapLinks Property
Calculating network links on the fly is an expensive procedure. If you have a large number of Devices that have
been assigned Locations, drawing those links on the map may take a long time. In order to save time, you can tell
Zenoss not to attempt to draw links for specific networks (for example, a local network comprising many devices
that you know does not span multiple Locations).
1. Navigate to the Network and click the "zProperties" tab.
2. Set the "zDrawMapLinks" property to "False."
3. Click "Save."
Like all zProperties, that setting will be inherited by all subnetworks. If you have few networks for which links
would be drawn, it might be a good idea to set zDrawMapLinks to False on /Networks, and only set it to True
on a network where you know a Location-spanning WAN connection exists.
5.1.5. Google Maps Example

This example will walk you through creating and displying some google map links of devices and sending a test
event to see how the links are affected by changes in the system.
35
Zenoss
1. Navigate to /Network, click "zProperties" and set "zDrawMapLinks" to False. Save.
2. Navigate to /Locations and create two sub-Locations, called "New York" and "Los Angeles".
3. Go to the Status tab of each of the two new Locations. Set the "Address" property of each to "New York, NY"
and "Los Angeles, CA" respectively.
4. Set the location of a device in Zenoss to /Locations/New York. Find another device on the same network and
set its location to /Locations/Los Angeles.
5. Navigate to /Locations and click on the "Map" tab. Notice that both New York and Los Angeles are represented
as dots on the map, but that there is no link drawn between the two.
6. Now navigate to the Network to which both devices are connected. Click the "zProperties" tab and set
"zDrawMapLinks" to True. Save.
7. Navigate back to the "Map" tab of /Locations. Notice that a green line is now drawn between New York and
Los Angeles.
8. Send an event (See Chapter 10, Section 4 of this guide) to the device in /Locations/New York, with a severity
of "Critical." Do not specify a component. Now refresh the /Locations "Map" tab. Notice that the New York
dot has become red. Also notice that the link between New York and Los Angeles remains green.
9. Now navigate to the New York device's "OS" tab and determine the id of the component that is connected to
the network shared with the Los Angeles device. Send another test event, but this time specify that component.
Now refresh the /Locations "Map" tab and notice that the line linking the two locations has become red.
5.2. Adding, Moving, and Nesting Locations

To create a new Location or Sub-Location:
1. From the Navigation menu on the left, under Browse by, select Locations.
The Sub-locations Status tab appears.
2. Open the Sub-Locations table menu to show Sub-Locations options.
3. Select the Add New Organizer option.
4. In the ID field, Enter the name for the new Sub-location.
5. Click OK.
The new sub-location is added and appears in the list.
5.2.1. Moving Sub-locations

To move the sub-location into another location or sub-location:
36
Zenoss
1. Select the location from the location list by clicking the check box next to the locations that you want to move
and then from the Sub-Locations table, select the Move Organizer option. The Move Organizer dialog appears.
2. From the pop-up menu, select where you want to move this location.
3. Click Move.
The location is moved to the selected location and the attributes page for the location where you moved the
location appears.
6. Inheritance
Inheritance is how many attributes are applied to device at different points in the device hierarchy. The following
diagram shows an example of how and where zProperties can be set throughout the device class tree.
Figure 7.10. Zenoss Device Class Tree and Inheritance
In this example, you can see that the default properties can be set at the highest level (/), as you go further down
the hierarchy, though, you can see that you can override any of the zProperties set at the root level. The next two
lines show how the device tree further defines properties for Linux servers. If you wanted to set up and use SNMP
monitoring for the all Linux servers (inclusive of) build.zenoss.loc, you can change these properties at the /Serv-
er/Linux level. Now if you wanted to change how you collected information for remote Linux servers (such as
dev.zenoss.loc) you can create a sub-group within the /Server/Linux group called /Server/Linux/Remote and set
these servers will use SSH monitoring and change the associated properties for that sub-group. Now also within
the /Server group you can create another sub-group for Windows servers that change the zProperties specifically
for WMI monitoring. All of these zProperties and groupings co-exist with any changes made lower in the hierarchy
taking priority. It is very similar to a directory tree only you can place items in multiple organizers.
37
Zenoss
7. Multiple Mix-In Inheritance and Performance (RRD)

Template Binding
Performance configurations are stored in objects called RRDTemplates, frequently just referred to as templates.
Templates contain other objects that define where and how to obtain performance data, thresholds for that data
and graphs of the data. A template can be defined anywhere in the Device Class hierarchy or on an individual
device.
The determination of which templates apply to what objects is called binding. There are two steps to binding: first
is determining which template names are appropriate and second is locating the correct templates with those names.
The template names used for components such as FileSystems, Interfaces, etc is the same as the components' meta
type. For example, file systems use templates name FileSystem. Devices are more complex because users can
modify the names of the templates to be used and can specify more than one name. This list of template names is
stored in the zDeviceTemplates zProperty. This zProperty can be edited directly on the zProperties page of any
Device or Device Class. It can also be edited through the Bind Templates menu item and dialog available from
the Templates page of any Device or Device Class. The second step of template binding is finding the correct
template with the given name. As with zProperties, templates can be defined directly on a Device or they can be
inherited from one of the Device Classes above it. The first templates found with the correct names searching up
the hierarchy are used. Any similarly named templates farther up the hierarchy are ignored.
7.1. Template Binding Example 1

You add a new device at /Devices/Server/Linux/Example1Server. You haven't edited its zDeviceTemplates so it
is inheriting the value of "Device" from the root Device Class, in this case "/Devices". Zenoss looks to see if there
is a template named Device defined on Example1Server itself. There is not, so it checks /Devices/Server/Linux.
There is a template named Device defined for that Device Class, so that template is used for Example1Server.
There is also a template named Device defined at /Devices, but that one isn't used in this case because the one at
/Devices/Server/Linux overrides it.
7.2. Template Binding Example 2

You want to perform specific monitoring of servers running a certain web application, but those servers are spread
across several different Device Classes. You create a new template at /Devices called WebApplication with the
appropriate Data Sources, Thresholds and Graphs. You then append the name "WebApplication" to the
zDeviceTemplates zProperty for the Devices Classes and/or individual Devices running this web application. (You
could use the Bind Templates menu item and dialog on the Templates page if you prefer instead of directly editing
zDeviceTemplates.)
38
Chapter 8. zProperties
1. About zProperties
The previous section hinted at zProperties and how they are inherited throughout the system. This section will
detail those zProperties and how to access them to set them, and what each one does.
zProperties are properties that Zenoss uses to specify various items that control the information in the system.
ZProperties are very powerful and can automate many tasks that are repeatable or things you would normally have
to do on an individual basis and apply them in many places or groups.
zProperties are configured either for all items, for an individual device, or for any devices that fall further down
in the hierarchy tree. zProperties are also zen-packable meaning the settings you set here will be added to any
ZenPack you create for wherever in the class hierarchy you are. zProperties exist for:
• Events
• Devices
• Services
• Networks
2. Event zProperties
To access Event zProperties, from the left navigation menu, select Event and click the zProperties tab. You can
also set zProperties for any event class in the events hierarchy by navigating to the level in the event hierarchy
where you want to set the zProperty and clicking the zProperties tab.
Table 8.1. Event zProperties

Property Name Property Type Description
zEventAction string Location to which an event will be
stored. Possible values are: status,
history and drop. Default is status
meaning the event will be an “active”
event. History sends the event directly
to the history table. Drop tells the sys-
tem to discard the event.
zEventClearClasses lines A list of classes that a clear event
should clear in addition to its own
class.
zEventSeverity int Allows you to override the severity
value of an event. If this is -1 it is ig-
nored. Possible values are 0 – 5.
3. Device zProperties
To access Device zProperties, from the left navigational menu, select Devices and then click the zProperties tab.
You can also select any of the Device Classes and the zProperties tab to set zProperties anywhere in the Device
hierarchy. To set zProperties for an individual Device, navigate to that device, open the page menu, select the
More option and then the zProperties tab.
39
zProperties
Table 8.2. Device zProperties

zCollectorClientTimeout int Allows you to set the timeout time of
the collector client in seconds
zCollectorDecoding string Converts incoming characters to Uni-
code.
zCollectorLogChanges boolean Switch to indicate whether to log
changes.
zCollectorPlugins lines A link to tall collector plugins for this
device.
zCommandCommandTimeout float Time to wait for a command to com-
plete.
zCommandCycleTime int The cycle time you use when execut-
ing zcommnads for this device or or-
ganizer.
zCommandExistanceTest string ***
zCommandLoginTimeout float Time to wait for a login prompt.
zCommandLoginTries int Number of times to attempt login.
zCommandPassword int Password to use when performing
command login.
zCommandPath string Default path where ZenCommand
plug-ins are installed on the local
Zenoss box or a remote box in the case
where SSH is used to run the com-
mand.
zCommandPort int Port to connect to when performing
command collection.
zCommandProtocol string Protocol to use when performing
command collection. Possible values
are ssh, telnet.
zCommandSearchPath lines Path to search for any commands.
zCommandUsername string Username to use when performing
command collection.
zDeviceTemplates lines Templates associated with this device.
Linked by name.
zFileSystemMapIgnoreNames string Regular expression of file system
names to ignore.
zFileSystemMapIgnoreTypes lines DO NOT USE
zIcon lines Icon to represent the device wherever
device Icon is shown (network map,
device status page etc.) Most devices
such as windows servers, linux serv-
ers, and routers have images set by
default
zIfDescription boolean Show the interface description field in
the interface list.
zInterfaceMapIgnoreNames string A regular expression filters out inter-
faces that should not be discovered.
40
zProperties

zInterfaceMapIgnoreTypes string A regular expression filters out inter-
face maps that should not be dis-
covered.
zIpServiceMapMaxPort int Highest port to scan, default to 1024.
zKeyPath lines Path to the key to access a device.
zLinks text Place to enter any links associated
with the device.
zLocalInterfaceNames string A regular expression that uses inter-
face name to determine whether or not
the IPs on an interface should be incor-
porated into zenoss' network map. for
instance a loopback interface "lo"
might be excluded.
zLocalIpAddresses int IP addresses that should be excluded
from the network map. for instance
127.x address most likely be excluded.
If you have addresses that you reuse
for connections between clustered
machines they might be added here as
well.
zMaxOIDPerRequest int The maximum number of OIDs to be
sent by zenoss' SNMP collection dae-
mons when querying information.
Some devices have small buffers for
handling this information so the num-
ber should be lowered.
zPingInterfaceDescription string A catalog query string that will find
interfaces to be pinged by description.
zPingInterfaceName string A catalog query string that will find
interfaces to be pinged by name.
zPingMonitorIgnore boolean Whether or not to ping the device.
zProdStateThreshold int Production state threshold at which
Zenoss will begin to monitor a device.
Default of 500 equals Pre-Productions.
zPythonClass string DO NOT USE
zRouteMapCollectOnlyIndirect boolean Only collect routes that are directly
connected to the device.
zRouteMapCollectOnlyLocal boolean Only collect local routes (these are
usually manually configured vs. those
learned through a routing protocol.)
zSnmpCommunities lines Array of SNMP community strings
that the ZenModeler will try to use
when collecting SNMP information.
zSnmpCommunity string Community to be used when collect-
ing SNMP information. If it is differ-
ent than what is found by ZenModeler,
it will be set on the modeled device.
zSnmpMonitorIgnore boolean Whether or not to ignore monitoring
SNMP on a device.
zSnmpPort int Port that the SNMP agent listens on.
41
zProperties

zSnmpTimeout float Timeout time in seconds for an SNMP
request
zSnmpTries int Amount of tries to collect snmp data
zSnmpVer string SNMP version used. Valid values are
v1, v2.
zStatusConnectTimeout The amount of time that zenstatus
should wait before marking an IP Ser-
vice down.
zSysedgeDiskMapIgnoreNames Currently unused.
zTelnetEnable boolean When logging into a Cisco device is-
sue the enable command to enable ac-
cess during command collection.
zTelnetEnableRegex string Regular expression to match the en-
able prompt.
zTelnetLoginRegex string Regular expression to match the login
prompt.
zTelnetPasswordRegex string Regular expression to match the pass-
word prompt.
zTelnetPromptTimeout float Time to wait for the telnet prompt to
return.
zTelnetSuccessRegexList lines List of regular expressions to match
the command prompt.
zTelnetTermLength boolean On a Cisco device, set term length to
Zero.
zWinEventlog boolean Whether or not to send the log.
zWinEventlogMinSeverity int Sets minimum severity to collect from
the win event log. Important to note
that the higher the number, the lover
the severity. 1 being the most sever
and 5 being the least severe.
zWinPassword string The password used to remotely login
if it is a Windows machine.
zWinServices
zWinUser string The user name used to remotely login
if it is a Windows machine.
zWmiMonitorIgnore boolean Use this to turn on or off all WMI
monitoring.
zXmlRpcMonitorIgnore boolean Use this to turn on or off all
XML/RPC monitoring.
4. Service zProperties
To access Service zProperties, from the left navigation menu, select Services and the click the zProperties tab.
You can also access the Services zProperties tab anywhere in the services hierarchy by going to the level where
you want to set the zProperty and clicking the zProperties tab.
42
zProperties
Table 8.3. Service zProperties

zFailSeverity int Determines what severity to send for
the specified service.
zHideFieldsFromList lines Fields to hide from Services instance
list
zMonitor boolean Tells whether or not to monitor a ser-
vice.
5. Network zProperties
To access Network zProperties, from the left navigation menu, select Networks and then click the zProperties tab.
You can also access the zProperties tab for any sub-network that exists with in the Networks page.
Table 8.4. Network zProperties

zAutoDiscover boolean Should zendisc perform auto-discov-
ery on this network
zDefaultNetworkTree lines List of netmask numbers to use when
creating network containers. Default
is 24, 32 which will make /24 net-
works at the top level of the networks
tree if a network us smaller than /24.
zPingFailThresh int Number of pings to sent without being
returned before Zendisc removes the
device.
6. Manufacturer zProperties
Table 8.5. Network zProperties
zDeviceClass string FUTURE USE
zDeviceGroup string FUTURE USE
zSystem string FUTURE USE
43
Chapter 9. Device Inventory and
Configuration
1. What is Inventory and Configuration in Zenoss?
Inventory and configuration refers to the population of the device database and also the collection of information
about the devices in the system. This is often referred to as “modeling”, and Zenoss can perform this process using
auto-discovery, one-at-a-time using the web UI, or both loaded via an XML file.
2. How Does Zenoss Model Devices?

Zenoss can model devices using SNMP, SSH, or the Telnet transport protocol. Each technique for modeling produces
a varying richness of information in the model. SNMP modeling often provides the most complete set of model
information, and SSH/Telnet is typically used to augment the model when an SNMP Agent does not report a spe-
cific piece of critical information.
3. The ZenModeler Daemon

Modeling is performed using the “ZenModeler” daemon. ZenModeler iterates over the list of devices in the system
and attempts to auto-discover the sub-components of each device. This includes network interfaces, file systems,
processes, and IP services (as well as others). By default, the system is setup to perform complete remodeling
every 6 hours. This may be too often for large deployments. Often this process is run only once per day from a
cron job.
4. Adding an Individual Device

Zenoss will add, model, and monitor those devices you add to the system. This section will walk you through
adding an individual device.
1. From the menu on the left side of the page, select Add Device.
The Add Device page appears.
44
Device Inventory and Configuration
Figure 9.1. Add Device - Full Page
2. In the Device Name field, enter the network (DNS) name or IP address of the device. Additionally, you can see
all of the fields and areas where you can add additional information about a device.
3. Choose a device class from the Device Class drop-down list. We will classify this sever as a windows server
so we choose /Server/Windows as the device class path.
4. Select a discovery protocol. You can choose from snmp, or none.
These methods are described in the above section about how Zenoss models devices.
5. Device Name, Device Class Path and Discovery Protocol are the only required fields for adding a device.
Zenoss will attempt to fill in the following fields or they can be filled in later. Information you add here may
conflict with information Zenoss discovers about the device.
NOTE: - When adding Cisco routers in classes other than /Network, you should set the zProperty for zIfDescrip-
tion to True. This will give you additional information about Cisco routers. The option is already set to True
by default for the /Network class.
45
6. Scroll down to the bottom of the page and click the Add Device button.
A Status page appears showing a log of the operations Zenoss is using to gather information about the device.
7. Scroll to the bottom of the page that results when you add a device. (You may have to scroll for a bit). There
will be a link you can click to navigate to a device. Click the link that says:
Navigate to device <device name>
The Main Device page appears showing the Status Tab.
Figure 9.2. Main Device Page
5. Add an Individual Device with Context

You can also add an individual device with context. This means that wherever in the hierarchy you choose to add
the device, that is where the device will appear in the hierarchy rather than the default of adding a device with no
context where the device goes into the /Discovered hierarchy by default.
To add a device with context:
1. Navigate to the place in the Device tree where you want to add the device.
This is the context part.
2. Open the page menu, select the Manage option and then the Add Device option.
46
The Add Device dialog appears.
Figure 9.3. Add Device with Context Dialog
3. Fill out the fields the same as when you add a device without context (The only difference here is that the Device
Class is pre-selected.)
4. Click OK.
The Device is added into the selected Device Class and the main Device page appears showing the Status Page.
6. Auto-Discovery of Devices
Zenoss can SNMP-walk the entire network and the routing tables and then model each individual device to add
them all at once to the database. The daemon that does this is called ZenDisc. To perform auto-discovery, the
machine on which Zenoss is installed must have an SNMP agent running.
To add all of the devices on a given network or subnetwork into the Zenoss system:
1. From the left navigation menu select networks.
The Networks Overview page appears.
47
Figure 9.4. Networks Overview Tab
2. Click the checkbox next to the network you want to add all of the devices from. You can also use Subnetworks
table menu to add a new network to the list.
3. Once you have selected the network, open the Subnetworks table menu and select Discover Devices.
4. The Discover Device page will appear showing you the status of all the device collections going on.
48
Figure 9.5. Auto-Discovery of Devices
This command will first model the monitoring machine and then walk through the routing tables of all routers
it can find. Auto-discovery will go as far as valid SNMP access is found or until a network is discovered in the
DMD that has its zAutoDiscover property set to False.
Routers discovered through this process will be placed in the device path /Network/Router.
When devices are discovered they are placed into the /Discovered device path. They should then be moved to
a more specific part of the tree. Servers are normally organized by OS, so windows machines might go to
/Server/Windows. Other information can be added to a device, like its Business System or its Location, using
the Edit tab on a device.
When devices are discovered they are placed into the /Discovered device path. They should then be moved to
a more specific part of the tree. Servers are normally organized by OS, so windows machines might go to
/Server/Windows. Other information can be added to a device, like its Business System or its Location, using
the Edit tab on a device.
7. Device List
The Device List shows a list of all the Devices in the system. You can search for all devices, see an event summary/
You can also perform some management tasks to apply to devices or groups of devices in the list.
To access the device list, from the left navigation menu, select Device List.
The Device List appears.
49
Figure 9.6. Device List
7.1. Managing Multiple Devices using the Device List

You can use the Device list page menu to manage multiple devices devices around by selecting the devices by
clicking in the boxes next to the devices you want to move and then selecting the appropriate menu option from
the menu.
Available options for managing multiple devices are:
• Move to class – for moving devices to new classes
• Set Groups – for assigning devices to groups
• Set Systems – for assigning devices to systems
• Set Location – for assigning devices to locations
• Set Monitor – for assigning monitors for collecting from selected devices
• Delete devices – for removing devices from the system
• Lock devices – for providing configuration locks for devices
8. Individual Device Tabs

Once Zenoss discovers and models a device it assigns certain properties and attributes to a device and classifies
these discoveries throughout a Device's information tabs. The following tabs are available when an individual
device is selected.
8.1. Device Status Tab

The Status tab is the default tab that is shown when you click on a device.
50
There is a Device Status table that shows important device status at a glance. The number of events grouped by
severity can be found on the left side of this table. You can click on the 'Event Rainbow' to view the list of events
for the device.
Also on the left side of the Device Status table is the device availability, uptime, last collection and modified time.
On the right side of the Device Status table is the Component Status list. Each item in the list is a type of device
component, which are IpService, WinService, IpRouteEntry, IpInterface, CPU, FileSystem, and Other. The status
of each device component type is determined by the collective status of the monitored components of the same
type. If the IpService status is green, then all monitored IpServices on this device are functioning normally. If there
is an event related to a monitored IpService, the component and highest severity event associated with that com-
ponent will be displayed in the status. If there is an event unrelated to a known component, it will be placed under
the component type Other. If you click on the component type, you will be sent to the OS tab of the Device where
you can manage the components on this device.
Figure 9.7. Individual Device - Status Tab
8.1.1. Device Status Tab Example

1. Click on the "OS" tab of any device. If you do not have an IpInterface eth0, add the interface by clicking the
"Add IpInterface" menu item in the "Add..." submenu. Once you have added the component you'll want it to
be monitored.
2. On the IpInterface edit screen, set Monitor to "True" and click "Save".
3. Now return to the Device Status page.
The IpInterface type should appear.
51
4. Now update the table by sending an event linked to a component and and not linked to any know components.
From the left navigation menu, click Events.
5. From the page menu, click on the "Add Event" menu item. Enter the name of the device. In the Component
field, enter "eth0". Leave the severity as "Critical" and click the "OK" button.
6. Now send another event, once again use the "Add Event" menu item. Enter the name of the device. In the
Component field, enter "Not a known component" (or any other string that isn't a name of a component on this
device) Set the severity to "Error" and click the "OK" button.
7. Now refresh the Device Status page.
You should see that the IpInterface type group has a component "eth0" with a red status indicating that a Crit-
ical event has been received.
8. If you click on the status bubble, you will be taken to the Events page for that device. You'll also notice that
you have a new type group, Other, with the component name we chose earlier. The status color of this component
should be orange which represents the Error event you created.
There is also a Device Information table that shows device details. The left side of the Device Information table
has the assigned organizers such as Location, Device Groups, Systems as well as the assigned status monitors
and performance monitor. You can click on a organizer or monitor to view the status page for the organizer or
monitor. The right side of the Device Information table includes data about the hardware and operating system
of the device.
8.2. OS (Operating Systems) Tab

The OS tab contains logical Operating System components such as:
• Interfaces
• IP Services
• Win Services (for Windows devices)
• File Systems
• Routes
• OS Processes
52
Figure 9.8. Individual Device - OS Tab
8.2.1. File System Monitoring

File system monitoring is only usable if the system has a good HOST-RESOURCES mib. File systems monitor
the amount of blocks used and show total bytes, available bytes, used bytes and percent used. You can set thresholds
to alert when a specific event occurs such as the disk reaches 90% utilization.
8.3. Hardware Tab

The Hardware tab gives you information about the device’s available/used memory, available/used swap and in-
formation on the CPU(s).
53
Figure 9.9. Individual Device Hardware Tab
8.4. Software Tab

The Software tab gives a list of all installed software. This software can be sorted by Manufacturer, Name or Install
Date.
Figure 9.10. Individual Device - Software Tab
54
8.5. Events Tab

The Events tab is very similar to other event views. You can sort events using several items including, but not
limited to, Component, EventClass and Count. You can also filter events by Severity, State or a regular expression
applied over all events. You can also can move, map or acknowledge Events here.
Figure 9.11. Individual Device - Events Tab
8.6. History Tab

The History tab shows the events that have finished with the event life cycle by some means and have been archived
in the history.
55
Figure 9.12. Individual Device - Status Tab
8.7. Performance Tab

The Perf tab shows performance graphs for the currently selected device. It displays Load Average 5 Min, CPU
Utilization, CPU Idle, Free Memory and Free Swap. This can be changed to update hourly, daily, weekly, monthly
or yearly.
56
Figure 9.13. Individual Device Performance tab
8.7.1. Graph Surfing

You can use the controls on the sides of the graph to “graph surf”. Graph surfing is when you use the controls on
the sides of the graph to change the graph and look at it in different ways. The arrows and magnifying glasses allow
you to see the data in different ways.
8.7.1.1. Linking the graphs together
The default is that all the graphs move in sync with one another so that if you click the back arrow for any graph,
they will all move backward, however you can keep it so that the arrow for each graph only works for that partic-
ular graph by un-checking the Link Graphs box.
8.7.1.2. Resetting the View
The Reset button returns to the default (initial view) of the graphs. Scrolling data back and forth horizontally. To
scroll data on the horizontally, use the arrows on either side of each graph. Each click will scroll the next unit back
and once you have scrolled data back, you can also use the arrows to scroll the graphs forward.
8.7.1.3. Zooming In on Data
You can also zoom in and out on the data that appears on graph by clicking the enlarge (+) magnifying glass or
zooming out by clicking on the (-) magnifying glass. You can use any combination of scrolling and zooming to
see the data exactly how you want to see it.
8.8. Edit Tab

Use this tab to change any of the properties of the device.
57
Figure 9.14. Individual Device - Edit Tab
8.9. Custom Tab

The Custom tab allows you to set values in the custom fields you define in Custom Schema. To access the Custom
tab, open the Device page menu, select More and then Custom.
58
Figure 9.15. Individual Device Custom Tab
8.10. zProperties Tab

The Device zProperties tab is where you can configure zProperties either for all devices, for an individual device,
or for any devices that fall further down in the device hierarchy tree. To configure them for all devices click the
zProperties tab from the Device Overview tab. To configure zProperties for an individual device, click on the
device name in the Device Overview and then click the zProperties tab for that device. To access the zProperties
tab, open the device table menu, select More and then zProperties.
59
Figure 9.16. Individual Device - zProperties Tab
8.11. Templates Tab

The template tab shows all of the performance templates bound by name to this device or group of devices. To
access the Templates tab, open the Device table menu, select More and then Templates.
Figure 9.17. Individual Device - Templates Tab
60
8.12. Administration Tab

To access the Administration tab, open the Device page menu, select More and then Administration.
Figure 9.18. Individual Device Administration Tab
8.13. Collector Plugins tab

The Collector Plugins tab shows you a list of all plugins available for the device. To access the Collector Plugins
tab, open the Device page menu, select More and then Collector Plugins.
61
Figure 9.19. Individual Device - Collector Plugins Tab
8.14. Modifications Tab

The Modifications tab logs user changes via the Zope interface. To access the Modifications tab, open the Device
page menu, select More and then Modifications.
Figure 9.20. Individual Device - Modifications Tab
62
9. Searching For a Device By Name or IP Address

The first and most prominent way to search for a device is to type in the name or IP of the device in the “Device/IP
Search” field at the top of the application. However this is not very useful if you cannot remember the name of
the device or are not looking for a specific device. In this case you can use the “Browse by” section of the left
navigation menu. Browse by allows you to browse by Systems, Groups, Locations and Reports. Browsing by
Systems allows you to browse by some common types of Devices such as File Servers, Printers and Infrastructure
and are arranged hierarchically. Browsing by Groups allows you to browse by groups that you can set up to organize
your devices. These groups can be named whatever you like and are arranged hierarchically. Browsing by Locations
is basically the same as the others, is just allows you to arrange your devices into groups based on location and
are arranged hierarchically as well.
10. Editing Device Configurations

If you wish to edit the configuration of a device, first locate the device either by using the “Browse By” menu or
by searching for the device in the search box at the top of the application. You can then edit the device configuration
by selecting the “Edit” tab of the device and changing any of the information. The following figure shows the Edit
tab for a Linux server.
Figure 9.21. Device - Edit Tab
63
11. Managing Devices

To manage various device attributes you can use the Manage menu item in the page menu for each device. The
options for this menu are More... Manage... and Run Commands... Use the Manage item to make all of the changes
described in the section below. It is also important to note that you can set up many of these management activities
according to the inheritance and hierarchies of the various device organizers. Just navigate to the organizer (Class,
System, Group or Location) and follow the same steps. Exceptions to this inheritance are noted in each section
below.
11.1. Remodeling a Device

To make Zenoss got to a device and recollect all of the configuration information for the device:
1. Navigate to the Device.
2. From the Device page menu, select Manage and then Model Device.
The Device is remodeled and the remodeling status page appears.
11.2. Changing the Device Class of a Device

To change the Device Class for a device:
2. From the Device page menu, select Manage and then Change Class.
The Device Class Change dialog appears.
Figure 9.22. Change Device Class Path Dialog
3. Select the new Device class for this device from the drop-down menu.
4. Click OK.
The device class for the current device has been changed.
11.3. Resetting Device Manage IP

To Reset the manage IP of a Device in the system:
2. From the Device page menu, select Manage and then Reset IP.
The Rest IP dialog appears.
64
Figure 9.23. Reset IP Dialog
3. Enter the new IP for the device (or leave it blank to all ow the IP to be set by DNS).
4. Click OK.
The IP for the device is reset.
11.4. Renaming a Device

To rename a device that is in the Zenoss system:
2. From the Device page menu, select Manage and then Rename Device.
Figure 9.24. Rename Device Dialog
3. In the ID field, enter the new name for the device.
4. Click OK.
The Device is renamed in the system.
11.5. Locking Device Configurations

You can lock a device's configuration in a few ways to prevent changes from being overwritten when remodeling
the device. There are two levels of locking that are available. You can Lock the configuration from deletion and
updates, or lock from deletion. You can also use this dialog to Unlock the device configuration.
2. From the Device page menu, select Manage and then Lock.
The Lock Configuration Confirmation Dialog appears.
65
Figure 9.25. Configuration Lock Editing Dialog
3. If you want to send events when actions are blocked by a lock click the checkbox.
4. Change the locking configuration by clicking the button for the lock configuration you want to set.
The lock is set for the device.
11.6. Resetting the Device Community

To change the Device community string:
2. From the Device page menu, select Manage and then select Reset Community.
The community for the device is reset.
11.7. Pushing Configuration Changes Back to the Zenoss System

You can push the any changes you make to the device configuration to the Zenoss system and the associated col-
lectors, without waiting for a remodel.
To push the changes:
2. From the Device page menu, select Manage and then select Push Changes.
A status message appears in the upper right of the screen confirming that the changes have been pushed up to
the collectors.
11.8. Clearing Heartbeats

To clear the heartbeats associated with a particular device:
2. From the Device page menu, select Manage and then select Clear Heartbeats.
The heartbeats for this device are moved to the event history.
The Edit tab for the ZenEventManager appears. Make any changes you want to make (if necessary)and click
Save.
66
11.9. Deleting Devices From the System

To delete a device from the Zenoss system:
2. From the Device page menu, select Manage and then select Delete Device.
The Delete Device Confirmation dialog appears.
Figure 9.26. Delete Device Confirmation Dialog
3. Click OK.
The Device is removed from the system.
12. Modeling Devices Using SNMP

This section various describes the methods used to model devices using SNMP.
12.1. Testing to See if a Device is Running SNMP

To test whether or not a device is running SNMP run:
$ snmpwalk -v1 -c communityString gate system
If this command does not time out, SNMP is installed and working correctly.
12.2. Modeling Remote Windows Devices Using SNMP

By default Windows may not have any SNMP installed. To install SNMP, go to Start -> Control Panel ->Add or
Remove Programs -> Add/Remove Windows Components. Check the box for Management and Monitoring tools
and install them. Next, you need to turn the services on and configure them, so go to Control Panel -> Administrative
Tools -> Services and start both SNMP Service and SNMP Trap Service. Set the SNMP Community string in the
SNMP Service properties to the community string of your SNMP. If you would like to monitor using WMI, refer
to the section about Zenwin.
If you want processor and memory monitoring, install SNMP-Informant on the device. Go to www.snmp-inform-
ant.com and download SNMP for Windows.
To collect Windows Event logs or log files from a windows box using syslog you can use SyslogAgent from ht-
tp://syslogserver.com/syslogagent.html. Windows event log can also be monitored using Zenwin’s native WMI
connection.
12.3. Modeling Remote Linux Devices Using SNMP

To configure a Linux machine for monitoring, it must have SNMP installed. A good Linux SNMP application is
net-snmp. Download, install and configure net-snmp and you can use SNMP to monitor Linux devices with Zenoss.
67
12.4. Modeling Cisco Devices Using SNMP

Cisco devices come with SNMP already installed. However, you have to configure SNMP on each Cisco device
to be in the same community as the rest of your network.
13. Modeling Using SSH/COMMAND

In some situations a system may not offer an SNMP Agent that Zenoss can securely access. This is often the case
when Zenoss is used to monitor production systems that only provide SSH access. Additionally, when SNMP
modeling is not available (or it does not provide a complete set of information), command plugins can be used to
model a device. Note: These “modeling” command plugins should not be confused with the “performance” command
plugins used elsewhere in Zenoss.
Each built-in zenoss modeling command plugin is differentiated by the platform on which it runs. To determine
the platform for the device you want to model, run the “uname” command in a shell on the device. The compatib-
ility options for the Zenoss modeling plugins are currently Linux or Darwin. The modeling command plugins can
be extended for platforms not listed above. However, the procedure for creating new modeling command plugins
is beyond the scope of the Administration Guide.
To model a device using command plugins, first you must add the device to zenoss using the protocol "none" and
then choose which plugins you wish to apply.
1. Go to the Add Device page.
2. Set discover to “None”.
3. Once the device is added, navigate to the device and view its zProperties tab.
4. If necessary, set zCommandUsername and zCommandPassword to the username and password of the device
(or set up passwordless authentication using RSA/DSA keys.)
5. Click “Edit” next to zCollectorPlugins.
6. Click Add Fields on the right to get a complete list of command plugins.
7. Make sure zenoss.cmd.uname is positioned first on the left hand side.
8. Click the X next to plugins you wish to remove, and drag other plugins over to the left.
9. Remodel the device.
13.1. Using Device Class to Monitor Devices Using SSH

The /Server/Cmd device class is an example configuration for modeling and monitoring devices using SSH. The
CollectorPlugins have been modified as described above, and the Device, Filesystem, and Ethernet interface tem-
plates used to gather data over SSH have been created. You can use this device class as a reference for your own
configuration; or, if you have a device that needs to be modeled or monitored via SSH/Command, you can place
it in this device class to use the preconfigured templates and zProperties. You will still need to set the zCommand-
Username and zCommandPassword zProperties to the appropriate SSH login information for each device.
68
14. Modeling Devices Using PortScan

You can also do a modeling of IP services by doing a port scan. To model the device using a port scan:
1. Go to the zProperties tab of a device.
2. Change the zTransportPreference to “portscan”.
3. Remodel the device.
14.1. Using the /Server/Scan Device Class to Monitor with Portscan

The /Server/Scan device class is an example configuration for modeling devices using a port scan. You can use
this device class as a reference for your own configuration; or, if you have a device that will use only a port scan,
you can place it under this device class and remodel the device.
15. Modeling Plugins

Zenoss uses plug-in maps to map real world information into the standard Zenoss model. Input to the plug-ins can
come from SNMP, SSH or Telnet. Selection of which plug-ins to run against a device is done by matching the
plug-in name against the zProperty, zCollectorPlugins. Plug-ins selected in zCollectorPlugins are the ones that are
collected.
• DeviceMap – collects basic information about a device such as its OS type and hardware model.
• InterfaceMap – collects the list of interfaces on a device.
• RouteMap – collects the routing table from the device.
• IpServicesMap – collects the IP services running on the device.
• FileSystemMap – collects the list of file systems on a device.
15.1. Getting a List of Modeling Plugins for a Device

Plugins are controlled by a regular expression that matches their name. You can get a list of plugins for any device
by navigating to the device and opening the page menu, selecting More and then Collector Plugins. The Collector
Plugins tab appears showing all of the collector plugins for the device.
16. Debugging the Modeling Process

The modeler can be run from the command line against a single device. This can be handy if you need to debug
an issue with a plugin. By passing the command “ --collect” to the modeler, you can control which collection maps
are used. This command will run only the interface plugin against a device called build.zenoss.loc:
$ zenmodeler run -v 10 --collect=IpInterface -d build.zenoss.loc
If it returns any stack traces, send them to our support team along with the command you ran and the version in-
formation of your Zenoss instance.
69
17. Using zLinks to Add Custom Links to a Device Status

Page
You can add custom links within Zenoss to associate with a device, device class, or hierarchy of devices. You can
use the zLinks zProperty to add links that will appear in the Status tab. Thes links are typically used to simplify
access to other control screens and drill-down interfaces available on the device.
To add links:
1. Select a device from the Device list where you want to add a custom link.
You can also create zLinks at the Device Class level to apply to all devices in the Class and also any devices
added to the class in the future.
2. From the device page menu, select More and then zProperties.
3. Scroll down to the zLinks zProperty.
4. Enter the link in the zLinks text field in the Value column.
You can use any URL expressions including http, telnet, file, mailto, etc. You can put other types of http markup,
including image references, such as the performance graphs from other pages.
5. Click Save.
The zLink is saved and will now appear on the Satus tab for the selected device.
18. Dumping and Loading Devices Using XML Lists

Zenoss allows you to export a list of your devices to an XML file for easy importing into another Zenoss instance.
From the command line, use the command:
zendevicedump -o mydevicelist.xml
This will dump the names of your devices, including their device classes, groups, systems etc. to a file called
mydevicelist.xml.
To load these devices into another Zenoss instance (or reload them into the same instance), while in the Zenoss
instance where you want the devices to be discovered, run the command:
zendeviceload -i mydevicelist.xml
Zenoss will then attempt to discover each of the devices in the XML file.
70
Chapter 10. Event Monitoring
1. About Event Monitoring In Zenoss
The Zenoss Event Management system can collect events from syslog, Windows event log, SNMP traps, and
XML-RPC. Processing is performed on raw events to integrate them tightly into the Zenoss model. Specifically,
an event is run through a set of rules to determine the class of the event, which can then provide additional inform-
ation such as event severity or up-down correlation.
2. Event Concepts
These are the primary concepts associated with Zenoss and its event monitoring system.
2.1. Event Life Cycle

The Zenoss Event Life Cycle is a very straightforward process. The first step of the life cycle is the creation of the
event. The default state of the event is set to “New”. The event can then be Acknowledged, Suppressed or “dropped”
with an Event class rule. From there, an event will be archived into the Event History database in one of four ways.
The event can manually be put into the history database; it can be put into the database due to auto clear correlation
(bad event happens, good event for the same thing happens, move bad event to history), an event class rule, and
an inactive timeout.
Figure 10.1. Event Life Cycle
2.2. De-duplication
If a single event is submitted multiple times for some reason, instead of the event clogging up the event log with
hundreds or perhaps even thousands of events, an event counter is incremented. The matching is done through the
event class. Additional matching event submissions do not generate more instances of that event in the event list,
but that they only increased the event counter. This is important so that the occurrences of the same event occurrences
do not create alert “chatter” in the time between when the event occurs and the time it takes you to acknowledge
or correct the event.
71
Event Monitoring
Figure 10.2. De-duplication
2.3. Begin-End Correlation

An event enters the Event Life Cycle at the start of the event, and at the end of the event, it leaves the life cycle.
If a positive event that corresponds to a negative event that has already been received, the associated negative
event is cleared. This is done by matching several key data points in the events themselves.
Figure 10.3. Begin-End Correlation
3. Zenoss Event Console

The Event Console is the central nervous system for event viewing. It is a repository for all events that come into
the system. To access the event console, from the left navigation menu, click Event Console.
72
Event Monitoring
The Event console appears.
Figure 10.4. Zenoss Event Console
When looking at events, there are quite a few sorting and filtering schemes available. Events can be sorted by
clicking on “device”, “component”, “eventClass”, “summary”, “firstTime”, “lastTime” and “count”. You can also
filter by state and severity or by using the “Filter” field. “Filter” is a regular expression on all text seen in the event
list. Events can be selected and either Acknowledged, moved to History, or Mapped into a specific location.
3.1. Viewing Event Details

You can view the details for any event in the system. To open the Event details window click on the magnifying
glass in the right-most column in the Event Console. The Event Detail window opens showing the Fields tab.
73
Event Monitoring
Figure 10.5. Event Details Fields Tab
This event details screen highlights the minutia for the event.
4. Generating and Sending a Test Event

You can use Zenoss to to add an artificial event to the event database to test your setups and mappings. To add a
new event:
1. From the left navigation menu, select Events.
The Events/Classes tab appears.
2. Open the Events page menu and select Add Event.
The Add Event Screen appears.
74
Event Monitoring
Figure 10.6. Add Event Dialog
3. Fill out the fields according to the kind of event you want to send. The following fields are available:
• Message
• Device
• Component
• Severity
• Event Class Key
• Event Class
The Event Console appears with your event at the top.
4.1. Sending Events from the Command Line

Zenoss allows you to send events TO Zenoss using a comman line tool. This script only relies on python, so it can
be moved easily to other systems. zensendevent uses the following options:
Usage:
zensendevent [options] summary words
Options:
• -d, --device
The local fully-qualified domain name
• -p, --component
Component from which this event is sent.
• -s, --severity
Severity of this event: Critical, Error, Warn, Info, Debug, Clear. Default: Warn
• -c, --class
Event class for this event
• --port
75
Event Monitoring
xmlrpc server port. Default: 8081
• --server
xmlrpc server. Default: localhost
• --auth
xmlrpc server auth. Default: admin:zenoss
Example:
zensendevent -c /App/Fail -p sky -s Critical Onos\! very bad message\!
5. Event Classes
The first integration step performed on a received event is assignment of the event class. Event classes are added
to the system using the hierarchical scheme found throughout Zenoss. Events are mapped to Event Classes by
Event Class instances. Event Class instances are looked up by a non-unique key called EventClassKey.
5.1. Creating a New Event Class

To create a new Event class:
1. From the left navigation menu, click Events.
2. If it is not already open, click the Classes tab.
3. Open the SubClasses table menu and select the Add Organizer option.
4. In the ID field, enter the name for the new Event Class.
5. Click OK.
The Event class appears in the SubClasses list.
6. Event Manager Settings

You can specify specific settings for the Event Manager. The settings you can change are the connection to the
MySQL Event Database, changing Event Cache timeouts and counts and make changes to the Event manager
Maintenance Settings.
76
Event Monitoring
6.1. Accessing Event Manager Settings

From the left navigation menu, select Event Manager. The Event Manager Settings Edit tab appears.
Figure 10.8. Event Manager Edit Tab
6.2. Changing Event Database Connection Information

Navigate to the Event Manager and in the Connection information area make any necessary changes. The available
connection information changes include:
• Backened Type – not editable at this point
• User Name – user name for the MySQL database
• Password – password for the user name identified above
• Database – which database to use
• Hostname – IP address or of the host
• Port – Port to use when accessing the event database
6.3. Changing Cache Settings for the Event Manager

Navigate to the Event Manager and in the Cache area make any necessary changes. The available Cache options
include:
• Cache Timeout – sets the cache timeout for the event monitor. the lower the setting the more responsive your
event console will be.
• Clear Cache Count – Clear the cache count for events (affects event counts, de-dup, etc.)
• History Cache Timeout – Sets the timeout for the History cache. Again the lower the number the more responsive
your history will be.
77
Event Monitoring
• History Cache Clear Count – clears the counts for the history.
6.4. Change the Maintenance Settings for the Event Manager

Navigate to the Event Manager and in the Maintenance area make any necessary changes. The available fields
include:
• Event Aging Threshold (hours)
• Don't Age This Severity and Above
• Default Availability Report (days)
• Default Syslog Priority
7. Acknowledging Events
Acknowledging Events is a way to let the system know that someone has seen the event and is either in progress
fixing it or has fixed it or is saying the problem is under control. The acknowledged status for the event is displayed
on the Dashboard.
To acknowledge an event:
1. Navigate to the event console.
2. Select the event you want to acknowledge from the Event Console by clicking the checkbox at the left of the
event.
3. Open the Events page menu and select the Acknowledge Events option.
Note the change in color (from deep red red to a pale red/pink) for the event you Acknowledged.
4. Return to the dashboard and note the name that appears in the “Acked By” column for the event (near the top
right of the screen).
8. Moving Events To History

Instead of deleting events, you manually send events to the event history. We call it “historifying” events. More
detailing about automating when events are sent to the event histopry can be found in the Event Life Cycle Section.
To send an event to the event history:
1. Navigate to the Event Console.
2. Select the event you want to send to history from the Event Console by clicking the checkbox at the left of the
event.
3. Navigate back to the Event console and select the same event (click the checkbox to the left of the event) scroll
to the bottom of the page and click the History Button.
4. Open the Event Console page menu and select the Move Events to History option.
A confirmation dialog appears.
5. Click OK.
78
Event Monitoring
Note that the event disappears from the Event Console.
9. Clearing The Event History

You can use the mySQL procedure clean_event_history to clear out the event history database if the database gets
too large to allow for reasonable speeds of data processing. From the command line, users can execute the MySQL
procedure like this:
$ mysql events -uzenoss -pzenoss -e 'call clean_history(12)'
The above example assumes the MySQL username is zenoss, and the password is zenoss, and the number of
months you want to keep is 12.
The only variable you need to pass is the “months” and this is the number of months back from where you want
to start to delete the history. For example, if you wanted to remove all events older than 12 months in the event
history database, enter 12.
10. Event Class Mapping

Event Class Maps are the mechanism by which the events are integrated into the Zenoss system.
The following diagram shows an example of an event class mapping:
Figure 10.9. Event Class Mapping
In this example, the event comes into the system it is parsed, and then assigned to the appropriate event class.
Then, as the event class key is found and associated with the event, then the context for that event class is applied
to the incoming event. Then the status for the event is updated based on its classification.
To create or update event class mappings:
1. From the left navigation menu, select Events.
2. Click the Mappings tab.
The Mappings page appears.
79
Event Monitoring
Figure 10.10. Event Mapping Page
3. Click the name of the Event Class Mapping you want to Edit.
The page for the Event mapping you have chosen appears.
80
Event Monitoring
Figure 10.11. IndividualEvent Mapping Page
4. Click the Edit tab.
The Edit Event mapping tab appears.
81
Event Monitoring
Figure 10.12. Edit Event Mapping Tab
5. Use the fields to define the Event Mapping.
The fields in this tab are defined as follows:
Name – Any name you want to call the Event Class Map.
Event Class Key – The Event Class key is what is initially used to map incoming events to event classes. For
syslog events, EventClassKey is most commonly the “Tag” or identifier of the syslog event. Often, the syslog
tag maps to the process name from which the event came.
Because the EventClassKey is non-unique, further matching may need to be performed to find a unique instance.
This matching can be done through mechanisms, regular expression match, or Python expression evaluation.
Because there will be list of instances against which these rules will be evaluated, the order of evaluation is
important.
Sequence – If there is more than one match you can use the Sequence field to define sequencing priorities. The
“Sequence” tab allows all instances for a particular EventClassKey to be ordered.
Rule – Enter a python expression to match to the event. This expression will be evaluated with the variable
name “evt” bound to the current event. A detailed list of fields can be found in the Event Database Dictionary
Appendix of the Admin Guide. An example of a rule using these fields would be:
evt.priority>4
Regex – The regex field is where you can enter regular expressions to match with events. When performing
regular expression matches on an event extraction directives can be used to populate attributes of the event.
These directives follow the Python format for named extractions in the form (?P<keyName>\S+).
82
Event Monitoring
Example - When creating a regular expression the original event text can be added to the example field and
upon save the regular expression will be tested against this text. It is a great debugging tool for regex expressions.
Transform – one or more python statements. This allows you to modify the event through manipulation of the
EVT variable. This section uses TALES Expressions, see the TALES Expressions section of this document for
more information on using these expressions.
Explanation - Enter a textual description for matches for this event class mapping. Use in conjunction with the
Resolution field.
Resolution - Use the Resolution field to enter resolution instructions for clearing the event.
If the EventClassKey lookup returns no results a second lookup will be performed using the key “defaultmap-
ping”. Default mappings can be used to match large ranges of events by regular expression.
6. Once you have made all of your changes, click the Save button.
11. Applying Event and Device Context Using Event

zProperties
Once an event has been mapped to its class, two things happen: (1) Its Event context is applied and (2) its Device
context(s) are applied. EventClass context application is done by looking up the zProperty list zEventProperties.
Any property names found in zEventProperties are set in the same way that other zProperties are, except that when
looking up the property, the prefix 'zEvent_' is added to the property name. When the zEventProperties value is
changed, Zenoss creates a placeholder for each of the properties in the list on the zProperties screen.
A common event property to change is 'Severity' and, in fact, Severity is added by default to zEventProperties. To
change the Severity of a classified event, change the value of zEvent_severity in the Event Class Path for the event.
After the event context has been applied, then the device context is applied. During this process, the productionState,
location, DeviceClass, DeviceGroups, and Systems, are all attached to the event in the event database. Once these
properties have been associated with the event, Zenoss attempts to update the zEventProperties (as described
above) but using the device class path instead of the event class path. This allows a particular device or class of
devices to override the default values for any given event.
To edit the Event zProperties:
1. From the main screen for any Event Class Mapping, select the zProperties tab for the Event Class mapping you
want to change.
The zProperties tab for that mapping appears.
83
Event Monitoring
Figure 10.13. Event Mapping zProperties
2. Use the fields to define the Event zproperties.
The three properties you can edit are:
zEventAction – zEventAction tells what to do when there is a match for this class. Your choices are Drop,
Status, and History.
zEventClearClasses – allows you to enter matches that send clear events when they appear on this particular
device.
zEventSeverity – gives the default severity for events of this class.
12. Mapping Events Through the UI

As events come into the system, sometimes Zenoss has not seen them before and does not know how to classify
them. As an administrator, you will classifying events and creating event maps through the UI. (So the event will
be managed the same way each time.)
1. Navigate to the Event Console.
2. Select the event you want to map in the console by clicking in the checkbox to the left of the event.
3. Open the Event Console page menu and select the Map Events to Class option.
The map events to class dialog appears.
84
Event Monitoring
Figure 10.14. Map Events Dialog
4. Select the event class where you want to map this event.
5. Click OK.
The event class for this event and events with the same parameters will now take on the characteristics defined
for the event class.
13. Using Mappings to Correlate Events

You can use Zenoss to create multiple event class mappings that can correlate two events and create an action
based on the occurrence of the two events. An example would be creating a correlation such as the beginning of
a failure with the end of a failure so that the clear event and then automatically move the event to the history
database.
1. Navigate to one of the event classes you want to correlate.
Click the Mappings tab. Create an additional mapping.
2. Click on the Classes tab again, then click on the mapping you just created, then click on its Edit tab.
3. Set Event Class Key back to the event class you want to correlate.
4. Make any changes to the Event Mapping fields you want such as adding the text “totally broken” in the Regex
field.
5. Make a second mapping in the same class with a related name to the first so you know its correlated with the
first mapping.
6. Set the Event Class Key the same event class key you set for the above event mapping.
7. Make any changes to the Event Mapping fields you want such as adding the text “everything is ok” in the Regex
field.
8. Go to the zProperties tab and set zEventSeverity to Clear (in the case where you want the 2nd event to create
a clear correlation). When this mapping matches the event will become a clear event and will clear all active
events of the same class.
9. Once this is done, go to the “Sequence” tab and notice that all three mappings with the same event class key
are listed here.
85
Event Monitoring
10. The order will control how the mappings are applied. Our first mapping will apply to all events with the given
event class key and will prevent our new rules from becoming active.
11. Put this mapping at the end of the sequence by changing its sequence number to 3 and clicking Save.
14. Event Commands

Event Commands allow users to define arbitrary shell commands to be executed when events are received by
Zenoss that meet the criteria defined in the event command. Event commands are carried out by the zenactions
daemon. We're going to create an event command that uses the mappings we created in the last section. Our
command will write text from our event into a log file.
14.1. Create an Event Command Example

This example will give you the framework for creating an event command.
1. Click on Event Manager and go to the Commands page.
2. Create a new event command called writeFile.
3. Edit the command with the following values.
Set Enabled = True
Default Command timeout = 60
Delay = 0
4. Set the command as follows:

echo "${evt/evid} ${dev/id} ${dev/manageIp} ${evt/message}" >> /tmp/cmdoutput
5. Set Clear Command

echo "${evt/evid} ${evt/clearid} ${dev/id} ${evt/message}"" >> /tmp/cmdoutput
6. In the Where area, add a filter of Message contains "testing event commands".
7. Click Save.
14.2. Test the Event Command

The Add Event page is a good tool for testing event commands. Follow these steps to create an event that meets
the criteria for the event command you just created.
1. Start watching the output file with the command:

tail -f /tmp/cmdoutput
2. Create an artificial down event using the Add Event functionality and defining it as follows:
Message = My Application is totally broken
Device = <any device in your system>
86
Event Monitoring
Event Class Key =
Severity = Critical
3. Look at the output file. After the next zenactions cycle you should see the down event.
4. Now let’s clear the down event by sending an up event.
Message = Now everything is ok
Device = <any device in your system -same device you used above>
Event Class Key =
Severity = Info
15. SNMP Traps and Event Transforms

15.1. SNMP Trap Mapping
If an SNMP trap comes in and is classified as an "/Unknown" event type, this is because Zenoss does not know
what you want to do with this event.
To map this event, from the Event Console, click the checkbox next to the unknown event, and from the page
menu, select Map Events to Class.
The Event Mapping dialog appears. Each category does different things to the event: changing its severity, moving
it to the history table, etc. For now, select "/App" and press the Map button.
To edit this mapping, from the left navigation, select Events and then click the Mappings tab. Search for and find
your Event map and then click the name of the map. Now click the Edit tab.
This will take you to the edit screen for an Event "Mapper". These are the rules used to map this event to the "/App"
category. This rule, since it matches the Trap by a very specific OID, is all you need.
In the "transform" section of the mapper, you can put some code to modify the summary. For example, lets say
you want to set the summary string to "spam Filter Detects Virus". You would put this in the transform edit area:
evt.summary = "spam Filter Detects Virus"
A trap has a header with some standard (and mostly useless) information. But then it has a sequence of attribute/val-
ues You can see these values as event details if you click on the last column of the event.
You have indicated you want the value for the OID ".1.3.6.1.4.1.9789.1500.2.5" as the summary. If you had the
MIB loaded, you could do this:
evt.summary = evt.spamFilterDetectsVirus
But... we have the OID and the data is still in there. We just need to use the slightly more cryptic:
evt.summary = getattr(evt, ".1.3.6.1.4.9789.1500.2.5", "Unexpected missing OID")
The "device" object for the event has been made available, too:
evt.summary = getattr(evt, ".1.3.6.1.4.9789.1500.2.5", "Unexpected missing OID") + " from device " + devic
Zenoss uses MIBs to translate SNMP Traps that contain raw OID values Loading a MIB into Zenoss allows it to
translate numeric OIDs like .1.3.6.1.2.1.1.6 into descriptive phrases like “sysLocation”. It also makes it easier to
manipulate the events in an event mapping.
87
Event Monitoring
Figure 10.15. SNMP Trap Transform
The following is a small demonstration MIB.

NOTIFICATION-TEST-MIB DEFINITIONS ::= BEGIN
IMPORTS
ucdavis FROM UCD-SNMP-MIB
NOTIFICATION-TYPE FROM SNMPv2-SMI
;
demonotifs OBJECT IDENTIFIER ::= { ucdavis 991 }
demo-notif NOTIFICATION-TYPE
OBJECTS { sysLocation }
STATUS current
DESCRIPTION "Just a test notification"
::= { demonotifs 17 }
END
15.2. Sending Test Traps

And here's how we send an SNMP trap.
1. From the command line, enter the following command:

$ snmptrap -v 2c -c public localhost '' 1.3.6.1.4.1.2021.991.1.3.6.1.2.1.1.6 s "Device in Annapolis"
2. Save this demonstration MIB into a file.
3. Send the trap.
4. Open the Event Console and find the trap you just sent.
5. In the far right column of the event console, click the magnifying glass in the far right column for the event you
just sent.
6. Click the Details tab.
You should see:
88
Event Monitoring
.1.3.6.1.2.1.1.6 Device in Annapolis
7. Send this event to the history.
You are now going to load some MIBs into Zenoss so we can get this OID translated into a more understandable
format.
1. Copy your demonstration MIB into $ZENHOME/share/mibs/site.
2. Run zenmib to load it into Zenoss:

$ zenmib run -v 10 DEBUG:zen.zenmib:TRAP-TEST-MIB.mib INFO:zen.zenmib:Unable to find a file providing t
3. Your MIB loaded, but it's missing some other definitions. They happen to be on the system somewhere else,
so you can copy them in:
$ cp /usr/share/snmp/mibs/SNMPv2-MIB.txt $ZENHOME/share/mibs/site $ cp /usr/share/snmp/mibs/UCD-SNMP-MI
4. Run zenmib again and get these loaded into Zenoss:

$ zenmib run -v 10
5. Send the trap a second time:

$ snmptrap -v 2c -c public localhost '' 1.3.6.1.4.1.2021.13.991 .1.3.6.1.2.1.1.6 s "Device in Annapolis
6. Now go check the event. Make sure the count is 1. If the count is 2, send the event to the history and send the
trap again. Look at the Details tab. Now you should see something like this:
sysLocation Device in Annapolis
You should also see that the event summary changes from:
snmp trap 1.3.6.1.4.1.2021.13.991 from localhost
to:
snmp trap ucdExperimental from localhost
While this is an improvement, we would like to get the “sysLocation” value “Device in Annapolis” into the
summary so that users do not have to drill down into the detail screen.
15.3. Transforming Events with Event Mappings

To modify events as they arrive, we will create an event map through the user interface as we did earlier. Create
a new Event Class.
Go to the event console and create an event mapping in this class from the existing event.
On the map go to the “Edit” tab. We can filter what events this mapping will work against. For example you could
filter on messages that contain the text ucdExperimental. Type “ucdExperimental” in the Regex field.
You can update the event with detail data in the Transform section. The entry field allows you to put in arbitrary
Python scripts. The event is provided as “evt” and the device as “dev”. In this case, we'll extract the sysLocation
event detail and make it the summary:
evt.summary = evt.sysLocation
Save this event mapping. Move all the events to history. Resend the trap. The summary for the trap should now
read the device name in the location you have assigned.
89
Event Monitoring
If you have any problems with the Transform, check the zentrap.log file for errors that occurred.
15.4. Event Transforms Based on Device Class

When an event arrives into the Zenoss system, values (such as severity) can be changed. For example, the summary
can be made more informative, or the severity changed according to some text within the summary.
Each Event Class allows for a short python script to be executed when an event arrives.
For example, a user may want full-filesystem threshold events on /data to be critical. The following python script
in the Threshold Transform of /Events/Perf/Filesystem:
if evt.component == '/data' and evt.severity != 0:
evt.severity == 5
Like event mappings for Event Class Keys, both "evt" and "device" objects are available within the script of the
transform.
16. Custom Event Views

In this activity, you will create and edit a custom event view so you can save views of the event list that have been
narrowed down according to filters you set and save. These custom event views are set on a per user basis.
To create a new custom event view:
1. Click the Preferences link in the top right of the dashboard.
2. Click the Event Views tab.
The Event Views tab appears.
Figure 10.16. Custom Event Views - Initial Views
3. Open the Event View table menu and select the Add Event View option. The Add Event View dialog appears.
90
Event Monitoring
Figure 10.17. Add Custom Event View
4. In the ID text field, enter the name for the new Custom Event View.
5. Click OK.
This custom event view appears in the list. Notice there is a custom alerting rainbow for this event view.
6. Click the link for the new event view you created.
Notice the size of the list and the number of entries.
7. Click the Edit tab.
The Edit Event views tab appears.
Figure 10.18. Custom Event Views - Edit Tab
8. Add conditions for this event view.
Type - Here you can select if you want to show active events or the event history.
Where - Use the Where area to add filters (similar to alerting rules where clauses.)
Order by - his determines the order of the entries in the view.
91
Event Monitoring
Result Fields: Result fields are the fields that appear in the view. For this activity, we will remove eventClass
from the view. Click the X next to eventClass in the Result Fields area.
9. Click Save.
10. Click the View tab to see the results of this Custom Event view.
92
Chapter 11. Availability Monitoring
1. Monitoring Topology with ZenPing
The availability monitoring system within Zenoss provides active testing of the IT Infrastructure. The system
currently consists of Zenping, Zenoss’ Layer-3 aware topology-monitoring daemon, and Zenstatus, a TCP status
tester.
ZenPing is configured automatically. You can use the About page, Status tab to stop and start Zenping. ZenPing
does the high-performance asynchronous testing of the ICMP status. The most important element of this daemon
is that Zenoss has built a compete model of the your routing system. If there are gaps in Zenoss’ routing model,
the power of ZenPing’s topology monitoring will not be available. If there are these gaps, this issue can be seen
in the zenping.log file.
Zenmodeler goes out and discovers the routes to each device in the Zenoss network. Zenoss tries not to use Internet
routing tables and prefers to rely on Zenmodeler to discover the relationships on its own and create its own network
map.
Basically if any known route is broken, there will only be one ping event that is generated by the outage. Any ad-
ditional outages beyond that will only flag that device and the next time a ping sweep occurs the errors beyond
the known router will not occur.
Zenmodeler works from the Zenoss system to further away from the server.
This monitoring model breaks down if the routers do not share their routing tables and interface information.
1.1. Controlling the Ping Cycle Time

1. From the left Navigation menu, select Monitors and select the Status monitor localhost and click the localhost
link.
2. Notice the list of machines being pinged by this monitor.
3. In the “Edit” tab, change “Cycle Interval” to the desired interval.
4. On the next configuration cycle, the ping monitor will ping at the interval you set.
1.2. Using the Predefined /Ping Device Class

The /Ping device class is an example of a configuration for devices that should only be monitored for availability.
Zenoss will not gather performance data for devices placed under this class; it will only ping them. You can use
it as a reference for your own configuration; or, if you have a device that you want be monitored for availability
alone, you can place it under this class.
2. Monitoring TCP Services

Use the Service menu to manage and monitor services that are running on your networks. To access the Services
pages, from the left Navigational menu, choose Services. The Services Overview appears.
The Services overview shows the folders and sub-folders and lists all of the services that have been added to the
system to monitor.
93
Availability Monitoring
2.1. Zenstatus
ZenStatus performs monitoring of TCP services. It is configured by turning on monitoring of a service under the
“Services” root on the Navigation Toolbar. Service monitoring can be turned on a service class but this can be
overridden on any service instance. For example, “SMTP” will be monitored by default but it may not be a critical
service on all boxes. If this is the case, it may be removed on specific devices. Also, if the service is configured
to only listen on localhost (127.0.0.1) the service will not be monitored.
2.2. Adding a Service To Monitor

To add a service to monitor:
1. From the Services Overview page, in the Services text field, enter the name of the service you want to monitor.
2. Click the Add button.
The service appears in the Services list.
Figure 11.1. Services List - Classes tab
3. To set monitoring to True, click the Edit tab and set the Monitor pop-up to True. The service is now being
monitored.
2.3. Monitoring Status Service Status Information

To view the status information associated with a given service, select the service from the Services list in the Services
Overview page.
The Individual Service Status tab appears.
94
Figure 11.2. Individual Service Status Tab
This tab shows you a summary of the details associated with this service. You can see the name of the service,
whether its monitored or not, a Description, any associated Service Keys and a List of Devices where the service
is currently running. To change any of this information, click the Edit tab.
2.4. Editing Service Information

To edit the information that appears on the Individual Service Status tab, from the Individual Services page, click
the Edit tab.
Figure 11.3. Individual Service- Edit Tab
95
From this screen, use the Monitor pop-up to select True to monitor the service and False to not monitor the service.
You can also add any associated Service Keys or enter a brief Description.
2.5. Configuring Service zProperties

You can configure zProperties either for all services, for an individual service or for any services that fall further
down in the service hierarchy tree. To configure them for all services click the zProperties tab from the Service
Overview tab. To configure zProperties for an individual service, click on the service name in the Service Overview
and then click the zProperties tab for that service. The Service zProperties Tab appears.
Figure 11.4. Individual Service - zProperties Tab
You can configure the following zProperties for an individual service from this tab:
• ZFailSeverity
• ZHideFieldsFromList
• zMonitor
For more information about the Services zProperties, see the zProperties Appendix.
2.6. Using the Predefined /Server/Scan Device Class

The /Server/Scan device class is an example configuration for monitoring TCP services on devices using a port
scan. You can use this device class as a reference for your own configuration; or, if you have a device that you
want to be monitored for service availability alone, you can place it under this device class. Zenoss will not collect
performance data for devices in this class.
2.7. Monitoring a Service Using a Service Class

This section will show you how to set up monitoring of an IP service across a group of devices using a service
class.
1. Navigate to the OS tab for a device you have loaded into the system.
96
The OS Tab for a device appears.
Figure 11.5. Showing Processes to Monitor
2. In the IP Services area, click the link to the service you want to monitor.
The service summary for the service you have selected appears.
Figure 11.6. Service Summary
97
3. From here set the Monitored flag to True to monitor this service for only this machine. You can also set this
service to be monitored system-wide.
4. To monitor a service system wide, click the Click the Service Class link.
This page will show you everywhere the service is running and whether the service is monitored or not.
5. Click the Edit tab and set Monitored to True.
This will turn on monitoring for every instance of this service in the system.
6. Click Save.
7. Click the Status tab once again.
Most of the instances of the Service will now be set to green, meaning they are monitored and up. The ones
that remain unmonitored indicate that they have this service class set to not monitor at a local level.
3. Monitoring Processes
Zenoss is able to monitor any processes running on your network. You can configure Zenoss to monitor process
as they occur throughout your system.
Zenoss process monitoring works according to how it appears in the following diagram:
Figure 11.7. Process Monitoring
You can see that ZenProcess uses a regex match to see if it can find PIDS matching the expression to see that these
process are running on the selected device.
3.1. Adding Processes to Monitor

To add a process to monitor:
1. From the left navigation menu, select Processes.
The Processes page appears.
98
Figure 11.8. Processes Page
2. From the Processes table menu, select Add Process.
The Add OS Process Dialog Appears.
Figure 11.9. Add OS Process Dialog
3. Enter the regular expression (regex) name of the process you want to monitor in the Processes field and click
the OK button.
The process is added and the Processes window re-appears showing the process you just entered.
Now you are monitoring this process, so after a remodel (which you can do manually or it occurs at 6 hour in-
tervals), it will show every device (occurrence) where this process is running. As such, the process is now being
monitored wherever it occurs.
Clicking on a specific process will take you to an interface that shows all instances of that process running
across machines that have it monitored. If the process has multiple instances the Zenoss will monitor the sum
of CPU and memory utilization of all processes as well as the count of total processes running. However, if the
process has only a single instance, CPU utilization and memory usage are graphed for the single process. To
perform process monitoring the device SNMP agent must have a reasonable HOST-RESOURCES mib.
99
3.2. Configuring Process zProperties

You can configure zProperties either for all processes for an individual process or for any processes that fall further
down in the process hierarchy tree. To configure them for all processes click the zProperties tab from the Process
Overview tab. To configure zProperties for an individual process, click on the process name in the Process Overview
and then click the zProperties tab for that process. The Process zProperties Tab appears.
Figure 11.10. Processes zProperties tab
You can configure the following zProperties for either all processes or the selected process from this tab:
• ZAlertOnRestart
• ZCountProcs
• ZFailSeverity
• zMonitor
For more information about the Services zProperties, see the zProperties Appendix.
100
Chapter 12. Performance Monitoring
1. Performance Monitoring
Zenoss includes several methods for monitoring performance metrics of devices and device components. ZenPerf-
SNMP collects data via SNMP from any device configured properly for SNMP monitoring. ZenCommand can
login to devices via telnet or ssh and run scripts to collect perforamnce data. ZenPacks can provide additional
means of collecting performance data. Examples include ZenJMX which collects data from enterprise java applic-
ations and HttpMonitor which checks the availability and responsiveness of web pages. Regardless of the monit-
oring method used, configuration information is stored in Performance Templates.
The following image shows that graph as it appears in the Perf tab.
Figure 12.1. Perf Tab showing Load Average Graph
The Performance Template for this Load Average 5 minutes graph (as for any other graph appearing on the Perf
tab) can be found by opening the Device page menu, choosing More.. and then the Templates option and then
clicking the name of the template.
2. Performance Templates
Performance Templates define the specific instructions for performance data collection for devices and device
components. Templates contain three types of sub objects: Data Sources, Thresholds and Graph Definitions. Data
Sources specify exactly which data points to collect and what method to use to collect them. Thresholds define
expected bounds for collected data and specify events to be created in Zenoss if the data does not match those
bounds. Graph Definitions describe how to graph the collected data on the device or device components Performance
or Status page.
101
Performance Monitoring
Figure 12.2. Performance Template for Load Average Graph
2.1. The Templates Page

The Templates page lists all the Templates available to a particular Device or Device Class. For Devices Classes
you can get to this page via the Templates tab. For Devices you use the page menu->More->Templates menu item.
The Templates page shows Performance Templates defined that that particular Device or Device Class and all
those defined further up the Device Class hierarchy. If more than one Template of the same name is defined then
only the one to which this Device or Device Class can bind is shown (the others have been overridden by that one.)
3. Template Binding
Templates can be defined on Devices Classes and on individual devices. Before Zenoss begins performance col-
lection for a device or component it must determine which Templates apply. This process is called template binding.
The first step to binding is determining the list of Template names that apply to this device or component. For
device components this is usually just the meta type of the component (e.g. FileSystem, CPU, HardDisk, etc.) For
devices this list is the zDeviceTemplates zProperty. The second step to binding is finding Templates that match
these names. For each name Zenoss searches first the Device then up the Device Class hierarchy looking for a
template with that name. Zenoss uses the first template it finds with the correct name, ignoring others of the same
name that might exist farther up the Device Class hierarchy.
102
The Templates page for any Device or Device Class shows the templates available for binding. This page shows
a list of all templates that are defined at this point or higher in the Device hierarchy. Use the Bind Templates menu
item to bring up the Bind Performance Templates dialog. This dialog lets you view and change which templates
are currently bound. You can edit the list of template names a device will bind to either by using the Bind Templates
dialog or by editing the zDeviceTemplates zProperty directly on the zProperties page. There is no way to edit the
bound name for a device component.
Name Binding Definition

Device The device object itself. (These OIDs don’t have an snmp
index number.)
FileSystem The file system object currently uses the host resources
MIB.
Interface Interfaces are bound using their interface type. For ex-
ample: ethernetCsmacd
HardDisk Hard disk object for I/O stats such as Windows boxes
with Informant MIB.
4. Data Sources
Data Sources specify exactly which data points to collect and how to collect them. Every Performance Template
has one or more Data Sources. Zenoss Core provides two builtin types of Data Sources: SNMP and COMMAND.
Other types can be provided through ZenPacks. When creating a new Data Source with the Add New DataSource
menu item you choose from a list of available Data Source types. All Data Source types will have a Name field
and an Enabled True/False option. Which other configuration options are presented depends on the type of Data
Source.
SNMP Data Sources define data to be collected via SNMP by the ZenPerfSNMP daemon. They contain one addi-
tional field to specify which SNMP OID to collect. Note that many OIDs need to end in .0 in order to work. Because
SNMP Data Sources specify exactly one performance metric they usually have exactly one Data Point (see below.)
See SNMP Monitoring section for further details.
COMMAND Data Sources specify data to be collected by a shell command that is executed on either the Zenoss
server itself or on the monitored device via a telnet or ssh session. The ZenCommand daemon processes COMMAND
Data Sources. A COMMAND Data Source might return one or more performance metrics and will usually have
one Data Point for each metric (see below.) Shell commands used with COMMAND Data Sources must return
data that conforms to the Nagios plug-in output specification. See the Monitoring Using ZenCommand section for
further details.
103
Figure 12.3. Data Source
5. Data Points
A single Data Source might return data on one or more performance metrics. Data Sources can contain one or
more Data Points to represent each individual metric retrieved by the Data Source. Data Points are created via the
Add DataPoint menu item when viewing a Data Source. Each Data Point has the following fields:
• Name - In the case of an SNMP Data Point this is usually the same name as the Data Source. For COMMAND
Data Points the name should be the same name used by the shell command in returning the data. See the plug-
in output specification mentioned above for details.
• Type - Zenoss uses RRDTool to store performance data. This field specifies which RRD data source type to
use in storing the data for this Data Point. The available options are COUNTER, DERIVE, ABSOLUTE,
GAUGE. A source declared as COUNTER will save the rate of change of the value over a step period. This
assumes that the value is always increasing (the difference between the current and the previous value is greater
than 0). Traffic counters on a router are an ideal candidate for using COUNTER. DERIVE is the same as
COUNTER, but it allows negative values as well. If you want to see the rate of change in free diskspace on your
server, then you might want to use the DERIVE. ABSOLUTE also saves the rate of change, but it assumes that
the previous value is set to 0. The difference between the current and the previous value is always equal to the
current value. Thus it just stores the current value divided by the step interval (300 seconds in our example).
GAUGE does not save the rate of change. It saves the actual value itself. There are no divisions or calculations.
Memory consumption in a server is a typical example of gauge. When debating choosing COUNTER you may
want to instead choose DERIVED and then a datapoint with a minimum of zero. This creates the same conditions
as the COUNTER with one notable exception. COUNTER is a ‚Äúsmart‚Äù data type. It can wrap the data
when a maximum number of values is reached in the system. An issue that can sometimes arise is a case when
there is a loss of reporting and the system (when looking at COUNTER values) thinks it should wrap the data.
This creates an artificial spike in the system and will create statistical anomalies.
• RRDMin - Any value received less than this number will be ignored.
• RRDMax - Any value received greater than this number will be ignored.
104
• Create Cmd - RRD expression used to create the database for this Data Point. If this is left blank then Zenoss
will use a reasonable default that is appropriate for most situations. Details on the create command can be found
at http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
Figure 12.4. Data Points
6. Thresholds
Thresholds define expected bounds for Data Points. When a Data Point goes outside a Threshold a Zenoss event
is created. Zenoss provides one builtin type of Threshold, the Min/Max Threshold. Mix/Max Thresholds inspect
incoming data to see if it exceeds a given maximum or falls belo a given minimum. ZenPacks can provide other
types of Thresholds. The fields for a Min/Max Threshold are:
• Name - This name is displayed on the Performance Template page and is used in creating Threshold events.
• Data Points - Select one or more of the Data Points from this Template to which this Threshold should apply.
• Min Value - If this field is not empty then any time one of the selected Data Points falls below this value an
event will be triggered. The field may contain a number or it may contain a Python expression. When using a
python expression the variable "here" is references the device or component for which data is being collected.
For example, an 85% threshold on an interface might be specified as: here.speed * .85 / 8. (The division by 8
is because interface speed is frequently reported in bytes/sec where the performance data is frequently bytes/sec.)
• Max Value - If this field is not empty then any time one of the selected Data Points goes above this value an
event will be triggered. Like Min Value above, it may contain a number or a Python expression.
• Event Class - The event triggered when this Threshold is breached will be of this Event Class.
• Severity - The first event triggered when this Threshold is breached will have this severity.
105
• Escalate Count - If the threshold is broken this many consecutive times the severity of the event will be escalated
one step.
• Enabled - Allows you to enable or disable this Threshold.
Figure 12.5. Threshold Definition
7. Graph Definitions
A Graph Definition contains the settings to produce a graphic representation of performance data on the device's
Perf page or on the component's Status page. These graphs can include any of the Data Points or Thresholds from
this Template. New Graph Definitions are created via the "Add Graph..." menu item on any Performance Template
page. There are several settings on the Graph Definition that determine the appearance of the graph:
• Name - The name of the graph as it will appear on the Perf or Status page.
• Height - The height of the graph in pixels.
• Width - The width of the graph in pixels
• Units - The label for the graph's vertical axis.
• Log - If True then the scale of the vertical axis will be logarithmic, if False then it is linear. This is useful in
situations where the data being graphed grows exponentially. Note that only positive data can be graphed logar-
ithmically.
• Base 1024 - Select True if the data you are graphing is measured in multiples of 1000 or 1024.
• Min Y - This sets the bottom value for the graph's vertical axis.
106
• Max Y - This sets the top value for the graph's vertical axis.
• Has Summary - If True then a summary of the data's current, average and maximum values is shown at the
bottom of the graph.
Figure 12.6. Graph Definition
7.1. Graph Points

Each Data Point or Threshold that is part of a graph is represented by a Graph Point. Several types of Graph Points
are available that correspond to Data Points, Thresholds or Custom graphing commands. You can add as many
Graph Points as you like to a Graph Definition. The Sequence field determines the order in which the Graph Points
are drawn on the graph. You can edit the Sequence numbers and reorder the Graph Points using the Re-sequence
Graph Points menu item. Note that Thresholds are always drawn before other Graph Points.
7.1.1. Data Point Graph Points

DataPoint Graph Points draw the value of Data Points from the Template on a graph. Add a new DataPoint Graph
Point to the Graph Definiton using the "Add DataPoint..." menu item. The Add GraphPoint dialog will appear al-
lowing you to select one or more Data Points defined in this Template. One DataPoint Graph Point will be created
for each DataPoint you select in this list. Additionally, there is a Include related thresholds checkbox. If this is
selected then any Graph Points will be created for any Thresholds that have been applied to the selected Data
Points as well. Clicking on the name of a Graph Point will take you to its edit page. This page will have different
fields for different types of Graph Points. DataPoint Graph Points have the following fields:
• Name - This is the name that appears on the Graph Definition page and by default is also the name that will be
used in the graph legend.
• Consolidation - This is the RRD function used to graph the Data Point's data to the size of the graph. For most
purposes the default value of AVERAGE is appropriate.
• RPN - You may enter an RPN expression that alters the value of the data being graphed for the Data Point. For
example, if the data is stored as bits but you would like to graph it as bytes you could use an RPN of "8,/" to
107
divide by 8. You can read more details of RRDTool RPN notation at http://oss.oetiker.ch/rrdtool/tut/rpntutori-
al.en.html
• Limit - You can specify a maximum value for the data being graphed.
• Line Type - Select Line to have the data graphed as a line. Selecting Area will cause the area between the line
and the horizontal axis to be filled with the same color as the line. You can select None if you want to use this
Data Point for Custom RRD commands but don't want it to be explicitly drawn.
• Line Width - Enter the pixel width of the line.
• Stacked - If True then the Line or Area is drawn above the previously drawn data. At any point in time on the
graph the value plotted for this data is the sum of the previously drawn data and the value of this Data Point at
this time. For example, if you were measuring packets in and packets out you could stack them to get an idea
of the total number of packets.
• Color - You may specify a color for the Line or Area. Some color names are recognized but more reliably you
can use a three or six digit hex value.
• Format - This is the RRD format to use when displaying values in the graph summary. Information on RRDTool
formatting strings can be found at http://oss.oetiker.ch/rrdtool/doc/rrdgraph_graph.en.html
• Legend - This is the name that will be used for this data in the graph legend. By default this is a TALES expression
that specifies the Graph Point name. The variables available in this TALES expression are here (the devicen or
component being graphed) and graphPoint (the Graph Point itself.)
• Available RRD Variables - This field lists the RRD variables already defined in this Graph Definition that could
be used in the RPN field.
7.1.2. Threshold Graph Points

Threshold Graph Points draw the value of Thresholds from the Template on a graph. Add a new Threshold Graph
Point to the Graph Definiton using the "Add Threshold..." menu item. The Add GraphPoint dialog will appear al-
lowing you to select one or more Thresholds defined in this Template. One Threshold Graph Point will be created
for each Threshold you select in this list. Threshold Graph Points have several settings: Name, Color and Legend.
See the section on DataPoint Graph Points above for a description of these fields.
7.1.3. Custom Graph Points

Custom Graph Points allow you to insert specific RRD graph commands into the Graph Definition. For details on
DEF, CDEF and VDEF commands see http://oss.oetiker.ch/rrdtool/doc/rrdgraph_data.en.html. For details on the
other RRD commands see http://oss.oetiker.ch/rrdtool/doc/rrdgraph_graph.en.html
7.2. Custom Graph Definition

The Graph Custom Definition tab allows you to specify exactly your own set of RRD commands to draw this
graph. The Graph Points specified on the Graph Definition tab are used to define data that is available to the
commands you specify here but the Graph Points will not be drawn unless you explicitly draw them with the
commands you specify here. The Available RRD Variables lists the values defined by the Graph Points that are
available for your use.
108
7.3. Graph Commands

The Graph Commands tab shows an approximate representation of the RRD commands that will be used to draw
this graph. It is mainly useful as a debugging tool when using Custom Graph Points or the Custom Definition tab.
8. Changing the Order of the Graphs

You can customize many of the features of the graphs including things like thresholds. As an example, you can
change the sequence of the appearance of the graphs on the page.
1. Navigate to a device in your system.
2. From the page menu, select More >> Templates.
3. Click the “Create Local Copy” button.
4. Click on the name of the template.
5. In the Graphs area of the page, use the Seq boxes to order the graphs on the page.
9. Monitoring A File System and Changing a Threshold

Zenoss also monitors File System Utilization.
To see File system statistics:
1. Navigate to the OS tab for a device you have loaded into the system.
2. Click the “/” File System.
Here you see a summary of the statistics for the file system for the device.
You can change the threshold for events to occur in the local template for this file system. This example walks
you through creating a low threshold and then generating events based on this new low threshold.
3. Click More and then Templates.
4. Click the Create Local Copy button to make a local copy of the template for this device.
5. In the Thresholds area, in the Add box, enter the name “Really Low Threshold” and click the Add button.
The Really Low Threshold appears in the list.
6. Click on the link for the Really Low Threshold.
7. Choose usedBlocks use Blocks
8. In the Max Value area, enter the following expression:

here.totalBlocks * .05
Basically this sets the really low threshold at 5% of usage.
109
9. Make sure Enabled is set to True.
You can leave the other values the same since we will gather this data from the same data-source and other at-
tributes.
You have now created a new threshold that you can create and send events based upon.
110
Chapter 13. Monitoring Devices
Remotely via SSH
1. Monitoring Devices Remotely via SSH
You can monitor device remotely via SSH. Monitoring devices remotely basically consists of 2 distinct installations.
You must install the Zenoss plugins on each remote device you want to monitor as detailed in the following sub-
sections.
1.1. Installing Zenoss Plugins on the Remote Machine

The Zenoss Plugins are packaged in 2 formats: native format and source distribution. The native format (RPM) is
recommended in Red Hat based systems that support Red Hat Package Management. Using the RPM distribution
allows system administrators to easily update the package when newer versions are released. The source distribution
is assembled using setuptools, and is commonly used by developers rather than system administrators. The benefit
of using the source distribution is that you do not need root privileges to install the Zenoss plugins.
1.1.1. Zenoss Plugin Installation Technique: RPM

The RPM for the zenoss plugins is a noarch RPM, which means it can be installed on any architecture (i386,
amd64, ia_64). The only external dependency needed to install the zenoss plugins RPM is python itself. Most
Linux distributions include python in their standard loads.
To install the zenoss plugins RPM use the following command:

$ sudo rpm -Uvh zenoss-plugins-*.rpm
Where 'zenoss-plugins-*.rpm' equals the latest Zenoss plugin RPM file.
1.1.2. Zenoss Plugin Installation Technique: setuptools

As noted above, the setuptools installation method allows non-rootusers to install and use the zenoss plugins. The
full set of setuptools arguments are supported, but most people will want to use the default build and install com-
mands:
$ python setup.py build
$ sudo python setup.py install
The above commands will install the Zenoss Plugins into directories that are accessible to all users. If you are unable
to install system software (because you are a nonprivileged user) you can still install and use the Zenoss Plugins.
However, you must go through some extra leg work to get the plugins installed. For a more detailed discussion of
how to install the plugins using a non-privileged account see the following URL:
http://dev.zenoss.org/trac/wiki/FAQ#HowdoIinstalltheZenossPlugins
An alternative to downloading the source tarball, exploding it, and running setup.py is to use setuptool's built-in
command 'easy_install'. To automatically download and install the zenoss plugins using easy_install run the fol-
lowing command:
$ sudo easy_install Zenoss-Plugins
Where 'Zenoss-Plugins' is the name of the current Zenoss plugin file.
111
Monitoring Devices Remotely via SSH
1.1.3. Testing the Plugin Installation

The entry point to the Zenoss Plugins is the zenplugin.py command. When run without any arguments, zenplugin.py
reports the proper usage of the script providing insight into which options should be run for troubleshooting.
The Zenoss Plugins detect platform specific runtime values using plugins. For example, the CPU plugin for the
linux2 platform uses /proc to read values. In comparison, the CPU plugin for the freebsd5 platform uses a different
technique. In order to test the installation you will need to determine which plugins are available for your platform.
To do this run the following command:
$ zenplugin.py --list-plugins
After determining a list of supported plugins for your platform run the zenplugin.py with the plugin name as the
argument. The following command line illustrates:
$ zenplugin.py cpu
1.1.4. Troubleshooting the Plugin Installation

1.1.4.1. "Command not found" when running zenplugin.py
If you receive a "command not found" when running the zenplugin.py command check to make sure that the dir-
ectory zenplugin.py was installed into is included in your PATH. If you installed via rpm you can use the command
"rpm -ql zenoss-plugins | grep zenplugin.py". If you installed via setuptools pay close attention to the "Installing..."
messages to see the full directory paths.
1.1.4.2. "platform 'XXX' is not implemented. no plugins exists"
This message indicates that no development work has been put towards implementing plugins for your particular
platform. If you receive this message and would like the plugins to support your platform mail the output of the
following command to the development team:
$ python -c 'import sys; print sys.platform'
1.1.5. Changing Zenoss to Monitor the Devices Remotely Using SSH

You must change the Zenoss properties for the group where you want to collect remote information using SSH.
1. Navigate to the device class path you want to monitor remotely. You can apply this monitoring per device or
per device class path.
2. Change the zProperties value for the group. Click the zProperties tab.
The zProperties tab appears.
112
Figure 13.1. Device Group zProperties Tab
You must make changes to the following zProperties:
• zCollectorPlugins
• zCommandPassword
• zCommandPath
• zCommandUsername
• zSnmpMonitorIgnore
• zTransportPreference
Here are the values we have setup on our remote devices. These have a pre-shared key (with no password)
setup from the collector to the remote boxes (it can also use password authorization if the password is entered
into zCommandPassword.
zProperties Value
zCollectorPlugins snmp|portscan
zCommandPassword The SSH password for the remote machine.
zCommandPath The path to zenplugin.py
zCommandUsername The SSH Username for the remote machine.
zSnmpMonitorIgnore True
zTransportPreference command
NOTE: It takes two passes to get full modeling. The first gets the platform type so we know what plugins to
run on the second pass which gives us interfaces, filesystems, etc. Run the command:
$ zenmodeler run -d enter_server_name_here
113
Run the command a second time to use the plug ins the command gathered on the first pass.
1.1.6. Using the Predefined /Server/Cmd Device Class

The /Server/Cmd device class is an example configuration for modeling and monitoring devices using SSH. The
zProperties have been modified as described above, and Device, Filesystem and Ethernet interface templates that
gather data over SSH have been created.
You can use this device class as a reference for your own configuration; or, if you have a device that needs to be
modeled or monitored via SSH/Command, you can place it under this device class to use the preconfigured templates
and zProperties. You will still need to set the zCommandUsername and zCommandPassword zProperties to the
appropriate SSH login information for each device.
114
Chapter 14. Monitoring Using
ZenCommand
1. About ZenCommands
Zenoss has the ability to run Nagios® or Cactii plug-ins though the process ZenCommand. In prior versions of
Zenoss, this was called Zenagios. ZenCommand can run plugins locally and remotely using a native SSH transport.
When run, Zenoss will track the return code of each plug-in and create events with the output from the plug-in.
Zenoss can track performance information from a plug-in also.
Figure 14.1. Running ZenCommands
2. Example: Writing a ZenCommand (check_http ex-

ample)
You can use a ZenCommand plugin (check_http) to check for specific content of a web page (implicitly checking
for server/page 200 status as well).
An example of setting up a ZenCommand plugin to check specific content is:
1. 1.Make sure you are the zenoss user.
2. Test the plugin from the command line. Once its working we will integrate it with Zenoss. check_http -h will
display all plugin options. Here is the command to test the product directory.
$ZENHOME/libexec/check_http -H www.zenoss.com
If the check_http command is correct, the output will look similar to the following.
HTTP OK HTTP/1.0 200 OK - 0.723 second response time |time=0.722758s;;;0.000000 size=7932B;;;0
You can see that this command plugin returns a valid value we are ready for the next step.
3.
115
Monitoring Using ZenCommand
4. Add the device you want to check (one running a www. website) to the Zenoss system setting the discovery
protocol to 'none'.
5. Navigate to the device in the Zenoss system and use the page menu to select More and then Templates.
6. Click Create Local Copy button.
You have now overridden the default Device template with one specific to this device.
7. Drill into the template and remove the sysUpTime data source since we won’t be using SNMP for this device.
8. Add a new description to the template something like “Web testing template”.
9. Add a new Data Source called rootWebCheck.
10. Drill into rootWebCheck and set the following variables:
• Source Type = COMMAND
• Component = rootWebCheck
• Cycle Time = 30
11. Debug your ZenCommand by running zencommand in the foreground with debugging on.
zencommand run -d www.website.com -v10
Where www.website.com is the site you are trying to monitor.
12. The command template field is a TALES expression so we can do some substitution in our command that will
make it generic for any device we add to this class. First let’s set the -H flag to be the IP of the device against
which this command will be run.
check_http -H ${here/manageIp}
13. Now let’s add a check looking for content on the page. The -r flag will run a regular expression against the web
page to check for text. We will look for three pieces of text:
check_http -H ${here/manageIp}-r textstring1
Where textsrting1 is some text you know to be displayed on the resulting webpage.
14. For this example, you want this command to be generic, so make a custom field for the regex that can be changed
per device. Set the default to “.*” which will match everything. Go to /Devices/Custom Schema and add a new
field:
• Label = Web Match Regex
• Name = cWebMatchRegex
• Type = string
• Default = .*
• Visible = True
15. Now go back our template and change the command to be.
116
check_http -H ${here/manageIp}-r ${here/cWebMatchRegex}
16. Now add the regex value into cWebMatchRegex that we used in the example above.
17. Test your ZenCommand from the command line.
3. Collect Data from A ZenCommand

To collect and display some data from the ZenCommand example above, you can log the data to see something
like response time in a graphical format.
1. Go to the /Web/Device template.
2. Go to the Data Source you created in the check_http example above.
3. At the bottom there is a table of Data Points add one called “responseTime”
4. The default type of GAUGE is fine so there is no need to modify the Data Point.
5. Test your command again and you should see a log message that starts with:
DEBUG:zen.zencommand:storing responseTime = 1.0
6. Make a graph to display your data. In the Device template, create a graph called “Web Response Time”.
7. For this graph, set the following values:
• Data Sources = rootWebCheck_responseTime
• Units = Seconds
• Min Y = 0
8. Now look at the Perf tab for the device www.website.com (whatever website you were using to check) to see
the graph. Graph data won’t show up until collection as run several times. Restart zencommand so that the new
configuration will take place immediately.
4. Plugin Format for ZenCommands

Nagios® plugins are configured using a Command Template that is much like the RRDTemplates used for per-
formance monitoring. So a template named “Device” will bind to all devices below the template definition.
Within each template is a list of commands that will run. The commands can be any program that follows the
Nagios® plug-in standard (inputs are command line arguments output is first line of stdout plus a return code) as
defined in:
http://nagiosplug.sourceforge.net/developer-guidelines.html
A Nagios® command has several fields:
• name – name of the command object
• enabled – should this command be used on a give device
• component – the component name to use when zencommand sends events to Zenoss
117
• event class – the event class to used when sending events to Zenoss
• severity – the default severity to use when sending events to Zenoss
• cycle time – how often a command should be run in seconds
• command template – the command to run
The command template string is built using Zope TALES. Several variables are passed when evaluating the
template. They are:
• zCommandPath – The path to the zencommand plug-ins on a given box it comes from the zProperty zCommand-
Path. zCommandPath will be automatically added to a command if a path is absent from the beginning of the
beginning of the command.
• devname – The device name of the device against which the command is being evaluated
• dev – The device object against which the command is being evaluated
• here – The context of evaluation. For a device, this is equivalent to dev for a component such as a filesystem or
interface this is the component object
• compname – If this command evaluates against a component, this is its name as a string
• now – The current time
Template values are accessed like shell variables. They are the same as the expression syntax used in the section
of this guide called TALES Expressions. Here are some examples:
Run an http check against all devices using the url /zport/dmd
check_http –H ${devname}-u /zport/dmd
In a template named FileSystem the following command will run against all FileSystems on a device.
check_disk –w 10% -c 5% -p ${compname}
5. Testing ZenCommands
ZenCommand Data Sources can be tested using the zentestcommand shell script. From the command line, simply
run:
zentestcommand –d devicename --datasource=datasourcename
Where devicename is the device you wish to run the command on and datasourcename is the name of a data source
on a template associated wih the device. zentestcommand will print the results of the command to stdout.
118
Chapter 15. Monitoring Windows
Devices
1. Device Preparation for Windows Devices
To monitor Windows devices, Zenoss requires a bit of setup. Make sure the following setup is performed.
1. The SNMP agent enabled.
This is done through Add/Remove programs -> Add/Remove Windows Components -> Management and
Monitoring Tools.
2. DCOM enabled for WMI connections.
3. Optionally, SNMP-Informant to have CPU, Memory and Disk I/O stats.
To monitor a Windows machine, you will likely want to use the Zenwin component (set up and installed separately)
to monitor WMI. To use Zenwin, please refer to the README.txt located in the Zenwin folder. If you do not want
to monitor WMI services, adding a Windows machine is the same as adding any other type of device, you will
just not be able to see the additional information available about the device through WMI.
2. Testing WMI on a Windows Server

1. Run wbemtest
2. Click “Connect…”
3. In the Namespace field enter \\HOST\root\cimv2
4. Enter login information in “User” and “Password” fields.
5. Click the “Query…” button.
6. Enter “select * from win32_service” should return a dialog with list of services on the box.
3. Other Optional Windows Configuration Items

1. Dell Open Manage agent gives detailed OS and hardware information.
2. HP Insight Manager gives detailed OS and hardware information.
4. ZenWin Command Line Parameters

The usage for the following Zenwin parameters is as follows:
$ZENHOME/bin/zenwin {run|start|stop|restart|status|help}[options]
Options Use
--version show program's version number and exit
119
Monitoring Windows Devices
Options Use
-h, --help show help message and exit
--hub-host=HUBHOST Host of zenhub daemon. Default is localhost.
--hub-port=HUBPORT Port zenhub listens on. Default is 8789.
--username=USERNAME Username for zenhub login. Default is admin.
--password=PASSWORD Password for zenhub login. Default is zenoss.
--monitor=MONITOR Name of monitor instance to use for configuration.
-v LOGSEVERITY, --logseverity=LOGSEVERITY Logging severity threshold
--logpath=LOGPATH Override default logging path
-C CONFIGFILE, --configfile=CONFIGFILE config file must define all params
--uid=UID user to become when running. Default: zenoss
-c, --cycle Cycle continuously on cycleInterval from zope
-D, --daemon Become a unix daemon
-d DEVICE, --device=DEVICE single device to collect
--debug=DEBUG turn on additional debugging
5. Modeling Services on Windows Devices

ZenWin is used for Windows Service Monitoring (WMI). It runs under windows and monitors the up/down
availability of windows services.
All Windows services are, by default, NOT monitored. If you would like to monitor a specific windows service,
it is very simple to turn it on.
Navigate to the Windows device and click the OS tab.
Click the service you want to monitor and change the value of monitor to “True”.
If you do not see the service you would like to monitor, click on the WinServices table menu.
Select the “Add WinService...” menu item.
6. Collecting Windows Eventlog Events

ZenEventlog also runs under windows, and is used collect (WMI) event log events.
Usage:
$ZENHOME/bin/zeneventlog {run|start|stop|restart|status|help [options]
Options Use
-h, --help show help message and exit
--hub-host=HUBHOST Host of zenhub daemon. Default is localhost.
--hub-port=HUBPORT Port zenhub listens on. Default is 8789.
--username=USERNAME Username for zenhub login. Default is admin.
--password=PASSWORD Password for zenhub login. Default is zenoss.
--monitor=MONITOR Name of monitor instance to use for configuration.
-v LOGSEVERITY, --logseverity=LOGSEVERITY Logging severity threshold
--logpath=LOGPATH Override default logging path
120
Options Use
-C CONFIGFILE, --configfile=CONFIGFILE config file must define all params
--uid=UID user to become when running. Default: zenoss
-D, --daemon Become a unix daemon
-d DEVICE, --device=DEVICE single device to collect
--debug=DEBUG turn on additional debugging
7. Monitoring Windows Performance with SNMP-Inform-

ant
Zenoss can use information from SNMP-informant to get SNMP information from windows devices. First, you
must install the free version of snmp-informant from: http://www.snmp-informant.com
To make sure SNMP Informant is running and setup correctly, run this command to walk the SNMP Informant
MIB:
snmpwalk -v1 -c<community> <server> 1.3.6.1.4.1.9600
This command will return some performance information if SNMP-informant is configured and running correctly.
Once this is configured properly SNMP information is gathered and used by the Zenoss system the same as any
other device sending SNMP traps.
8. Running Commands on Windows Servers Using

Winexe
You can use winexe commands to run commands on monitored Windows servers from within Zenoss.
Usage:
$ZENHOME/bin/winexe [options] //host [command]
Options Use
--uninstall Uninstall winexe service after remote execution
--reinstall Reinstall winexe service before remote execution
--system Use SYSTEM account
--runas=[DOMAIN\]USERNAME%PASSWORD Run as user (BEWARE: password is sent in cleartext
over net)
Help Options Use

-?, --help Show this help message
--usage Display brief usage message
Common samba options Use

-d, --debuglevel=DEBUGLEVEL Set debug level
--debug-stderr Send debug output to STDERR
-s, --configfile=CONFIGFILE Use alternative configuration file
--option=name=value Set smb.conf option from command line
-l, --log-basename=LOGFILEBASE Basename for log/debug files
121
Common samba options Use

--leak-report enable talloc leak reporting on exit
--leak-report-full enable full talloc leak reporting on exit
-V, --version Print version
Connection Options Use

-R, --name-resolve=NAME-RESOLVE-ORDER Use these name resolution services only
-O, --socket-options=SOCKETOPTIONS socket options to use
-n, --netbiosname=NETBIOSNAME Primary netbios name
-W, --workgroup=WORKGROUP Set the workgroup name
--realm=REALM Set the realm name
-i, --scope=SCOPE Use this Netbios scope
-m, --maxprotocol=MAXPROTOCOL Set max protocol level
Authentication Options Use

-U, --user=[DOMAIN\]USERNAME[%PASSWORD] Set the network username
-N, --no-pass Don't ask for a password
--password=STRING Password
-A, --authentication-file=FILE Get the credentials from a file
-S, --signing=on|off|required Set the client signing state
-P, --machine-pass Use stored machine account password (implies -k)
--simple-bind-dn=STRING DN to use for a simple bind
-k, --kerberos=STRING Use Kerberos
--use-security-mechanisms=STRING Restricted list of authentication mechanisms available
for use with this authentication
122
Chapter 16. SNMP Monitoring
1. SNMP from the Command Line
OID represent the data points where the data for the graphs comes from. Sometimes the reason that a graph is not
appearing is because the OID for the particular graph is not valid for the device. You can test this validity using
the command line to see if you can return a value. To test the validity of an OID data point giving performance
data:
1. SSH to the Zenoss instance.
Use Username: root
Password: zenoss
2. Run the command snmp get for one of the OIDs
In this case lets use the command:

$ snmpget -v1 -cpublic build .1.3.6.1.4.1.2021.4.14.0
If the OID is valid it will return a value.
Here are some basic SNMP Operators to gather certain information.
a. Walk a basic system MIB.

snmpwalk -v1 -cpublic <device name> system
b. Walk an interface description

snmpwalk -v1 -cpublic <device name> ifDescr
c. Get a single value.
snmpget -v1 -cpublic <device name> ifDescr.2
d. Detailed description of an OID value.

snmptranslate -Td RFC1213-MIB::ifDescr
e. Convert a name to a raw OID.

snmptranslate -On RFC1213-MIB::ifDescr
f. Convert a raw OID to a short name

snmptranslate -OS .1.3.6.1.2.1.2.2.1.2
123
Chapter 17. Alerting Rules
1. Creating and Using Alerts
The daemon ZenActions provides functionality for sending emails or pages based on events received. It continuously
evaluates every user’s paging rules against the event database. Each user has their own set of alerting rules.
Figure 17.1. Sending Alerts
1.1. Setting SMTP Settings For Alerts

To use email and pager alerts, you must have Zenoss pointing to an SMTP relay with the proper settings.
1. From the navigation menu on the left side of the Dashboard, select Settings.
The Settings page appears.
124
Alerting Rules
Figure 17.2. Settings Tab Showing SMTP Settings
2. To set up the mail servers, you must configure the SMTP Host, the SMTP Port, SNPP Host, and the SNPP Port.
Now you are prepared to create and use Alerting Rules for the Zenoss system.
2. Creating a New Alerting Rule

Alerting rules are created on a per user basis. You can add additional recipients for rules, but upon creation, the
rules are tied to a user account.
1. From the upper right corner of the Zenoss Dashboard, click the Preferences link.
The Preferences page appears.
125
Alerting Rules
Figure 17.3. Preferences Tab - Edit Tab
2. Select the Alerting Rules tab.
The Alerting Rules tab appears.
Figure 17.4. Alerting Rules Tab
3. From the Alerting rule table menu, select Add Alerting Rule.
126
Alerting Rules
The Add Alerting Rule dialog appears.
Figure 17.5. Add Alerting Rule Dialog
4. In the ID field, enter a name for the alert.
The main Alerting Rules page appears showing the alert you just created.
6. Click the name of the Alert you just created.
The Alert Details page appears.
Figure 17.6. Alert Details Edit Page
2.1. Define and Enable This Alert

Set the attributes from the Alert Details page, and clicking the Edit tab.
1. Use the Delay field to set the number of seconds to wait before sending the alert. If an event clears before delay
time no alert is sent.
127
Alerting Rules
2. To enable the alert, set Enabled to True.
3. Use the Repeat Time to set the time for repeating the alert to send the alert every x seconds until the event is
acknowledged.
4. In the Action field, select whether you want the system to send email or a page.
If action is defined as email the event will be emailed. If the default action is set to page, you will need to have
an SNMP paging server setup (see the external libs dir of install directory and the sendpage lib does this). Many
wireless phone systems have SMTP to SMS gateways so in many cases you use email to act like a page as well.
By default email alerts will be sent to the email address for this user and pager alerts will go to the specified
pager address.
You can override this by filling in the Address (optional) field.
5. The Where area of the tab sets the thresholds for the Alert.
The default rule that is created contains the thresholds for an event occurrence where the Event State is “New”,
Severity is “greater than Error”, and Production State is “Production”. You can change these thresholds by
changing the values in the pop-up menus.
6. You can also add additional filters to the Where area by choosing a filter from the Add Filter menu. Adding a
filter creates an additional pop-menu in the Where area where you can choose additional values to filter the
event. To Remove any of the filters for the alert, click the (-) minus button.
7. Click Save to save the values you entered on this tab.
2.2. 1.1.1 Create the Content of the Alert Message

1. From the Alerting Rules Page, click the Message tab to customize the message that is sent to the specified address.
The Message tab appears.
128
Alerting Rules
Figure 17.7. Alerting Rules Message Tab
2. Use the Message tab to specify the email message subject and body. You actually have two (2) message to
create. The first (called Message) is the message to send when the thresholds for the alert are met or exceeded.
The second message is the one to send when the event has cleared (called Clear Message).
The fields for the subject and message areas are python format strings.
At the bottom of the page there is a list of the fields available for an alert. A clear events fields are accessed by
prefixing the field name with “clear”. For instance the field prodState becomes clearProdState. There is also a
special field clearOrEventSummary which will print the clear summary or if it does not exist the original alert
summary. This is useful for the subject of a clear alert. In the case where an alert has no clear (it was deleted
for the UI for instance) a meaning full subject will still be created.
3. Click Save to save the data you entered on this page.
2.3. Create a Schedule for Sending the Alert

1. From the Alerting Rules page, click the Schedule tab to set up a schedule for the Alert.
The Schedule tab appears.
129
Alerting Rules
Figure 17.8. Alerting Rules - Schedule Tab
2. To add a new Schedule for the Alert, from the Active Periods table menu, select Add Rule Window.
The Add Active Period dialog appears.
Figure 17.9. Add Active Period Dialog
3. Enter a name for the schedule in the ID field and click the OK button.
The Schedule you added appears in the Active Periods list.
4. Click the name of the new Schedule to set the details for the schedule.
The Schedule Details page appears.
130
Alerting Rules
Figure 17.10. Alerting Rules - Schedule Details Page
5. If you want to restrict this Alert to only monitor at certain times for certain durations, set the Enabled field to
True.
6. In the Start area, enter the date you want the alert to start, or click the Select button to choose the date from a
calendar.
7. In the fields to the right of the date, select an hour and minute for the Alert to start.
8. Use the Duration area to specify the length of time you want to Alert to be listening based on the start time.
9. If you want the Alerting period to repeat you can choose a time frame from the Repeat pop-up menu. You can
choose from:
• Never
• Daily
• Every Weekday
• Weekly
• Monthly
• First Sunday of the Month
10. Choose a number of times to repeat the selected interval.
11. Click Save.
You have now saved all of the options for creating a new alert.
131
Alerting Rules
3. Escalation of Messaging in Zenoss

You can create a messaging hierarchy using some of the different managing tools available in Zenoss.
3.1. Creating an Alerting Hierarchy

You can create a alert Hierarchy based on event status and delays using Alerting Rules. For example, you send an
alert to Person A (for example the first level, on call tech) as soon as any event of a given priority occurs, if that
event is not Acknowledged or Suppressed (changing the status of the event) within a given time frame (For example,
an hour) you create an additional alerting rule to send email to the next person in the Alert Hierarchy, for example
Person B.
To create this hierarchy, first, you create an Alerting Rule for the Default case (the initial state). This case is "Any
when any new event of whatever priority occurs, alert Person A. To create this default rule, just create the Alerting
rule as usual. Set the Delay at 0 (Zero) seconds. Now for the next level in the alerting hierarchy (Person B) you
want to say "OK, if Person A does not acknowledge or suppress the event within an hour - then send an Alert to
the next person in the hierarchy (Person B). To create this hierarchy in Zenoss, you have to create an additional
alerting rule for Person B. There are 2 ways of doing this - you can A) Create an additional rule for the User account
you are currently logged in as or B) You can just add the additional (Person B's email address in the Address (op-
tional field). This added address overrides the User account email so email will only be sent to the newly added
email address.
For the 2nd Alerting Rule, set the delay to the number of seconds you want to wait after an event has come in and
has not been acknowledged or cleared. For our example, we have determined that time-frame to be one hour. One
hour is 3600 seconds. So in the Delay box for the Alerting Rule, enter 3600.
Now we need to pass a condition that will keep this alert from firing on all events, even the ones that Person A
acknowledges or Suppresses before the hour expires. In the Add filter area, select Event State and then select the
event state that will keep this rule from being executed on ALL events, even ones acknowledged by Person A. In
this case, an Event is considered to have a state of New unless it has been either Suppressed or Acknowledged so
let’s leave the setting at New. So now this alerting rule will send email to Person 2's email if an event remains in
the New State for more than 3600 seconds (one hour)
So this section defines a small 2 person hierarchy, but you can use the filters for alerting rules to create much more
sophisticated alerting hierarchies and scenarios. Device priority is a new attribute that will work great for defining
which person gets which alerts unless a device has a certain priority level in which case everyone gets the alert.
4. Adding Delay and Schedules to Alerting Rules

You can use Delays when creating alerting rules to set up on-call schedules and elevation hierarchies. Using delay
will allow you to specify that if an event is not acknowledged in a certain amount of time, then send email to the
next person in the hierarchy. You accomplish this by filtering on event state ('New' not acknowledged) and adding
a delay. Create an alerting rule for the tier 1 support person that does not have a delay so they find out immediately
and can acknowledge the event if possible.
1. Create a second alerting rule (this one will be for the tier 2 person in the hierarchy) and enable it.
2. Use the 'where' clause to say this rule is only in effect for events that have not been acknowledged.
Delay = 300 (in seconds, 5 minutes)
In the Where area,
Production State = Production
Severity >= Error
Event State = New
132
Alerting Rules
This rule now says fire this alert if there is an event in the system that is New (not acknowledged) for 5 minutes
send email to this user.
3. Click the Message tab and in the Message (or subject) field enter the following:
[Zenoss-delayed] %(device)s %(summary)s
4. In the Clear message (or Subject) area, enter the following.
[Zenoss-delayed] CLEAR: %(device)s %(clearOrEventSummary)s
5. Click the Schedule tab to edit the schedule. You can tell the rule to only be active when this user is on call (re-
member each alerting rule is user based).
6. In the Add field enter a name for the new schedule.
7. The new schedule appears in the list. Click the name of the new schedule.
Name = name of the new schedule
Enabled = True
Start = whenever you want the rule to start
Duration = how long you want this rule to be in effect
Repeat = number of times to repeat the schedule
Every = how many of the time periods to repeat for
8. Click Save.
133
Chapter 18. UI Commands
1. About UI Commands
User commands allow users to execute arbitrary shell commands from within Zenoss. These commands can then
be run manually against a single device or a group of devices. The user commands are executed on the Zenoss
server, not on the remote device (unless the user command explicitly uses ssh to connect to the remote device.)
User commands can be defined on any device class, system, group or location. They can also be defined globally
from the Settings page under the Manage tab.
2. Defining UI Commands
1. To access the Define Commands area, from any device you have loaded into your system, open the Device
page menu, select More >> Administration.
The Administration tab appears.
2. From Define Commands table menu, select Add User Command.
The Add User Command dialog appears.
Figure 18.1. Add User Command Dialog
3. In the Command Id field, enter a name for the command and click OK.
The Define Command page appears.
134
UI Commands
Figure 18.2. Define User Command Dialog
4. In the Description field, brief description of what the command will do.
5. In the Command section, enter the TALES expression based command you want to be run on the selected device
or devices.
The Command is saved and added to the command drop-down menu so you can choose to run it at any time.
2.1. UI Command Example: Echo Command

This section will walk you through creating an echo UI command. You can see the use of TALES expressions in
the definition of this command as in many other commands in Zenoss.
1. Go to the Settings - Manage tab.
2. Add a new command called “echoDevice”
3. Echo the name and IP of the device

echo name = ${here/id} ip = ${here/manageIp}
In a TALES expression ‘here’ is the object that the expression is executed against. Some TALES expressions
in Zenoss have other variables like evt for event and dev or device for the device. See the TALES Expression
appendix for more information on the syntax of the various TALES expressions.
4. Go to a device and run this command.
5. Now go back to the editing of this command and add some more information to the command.
135
UI Commands
echo name = ${here/id} ip = ${here/manageIp} hw = ${here/getHWProductName}
6. Now try running the command against a group of devices and see the command outputs.
3. Running Commands from the Zenoss Web UI

Zenoss allows commands to be run though the user interface. It comes with several built in commands such as
ping and traceroute. Commands can be run on a single device or on a group of devices.
You can run a command one time on a device or group of device from the Zenoss System.
1. Navigate to the Device or Device Group where you want to run the command (and where you have the command
defined).
2. 1.From the Device page menu, select Run Commands and then the command name you want to run.
The command is run and the output appears on the screen.
Figure 18.3. Command Output
4. Auto-Running Commands Based on Events

Zenoss allows you to set up commands to automatically be run against a device based on an event entering into
the system.
To run events based on Events:
1. 1.From the Zenoss Dashboard, from the left navigation menu, in the Management area, select Event Manager.
The Event Manager Edit tab appears.
2. Click the Commands tab.
The Commands tab appears.
136
UI Commands
3. Enter a name for the new Command, and click the Add button.
The new command appears in the command list.
4. Click on the name of the new command in the command list to give the command its attributes.
The Edit Command window appears.
Figure 18.4. Edit Event Command Page
5. Enable the command by setting the Enabled box to True.
6. Now set the other attributes for the command change the default timeout if necessary. Default timeout for the
command is 60 seconds.
7. You can also change the delay for the command so there is a gap between when the conditions for the command
to be run are met and when the command actually runs.
8. In the Command area, enter the command you want to run when the conditions are met. These commands use
TALES expressions. (See the section on TALES Expressions for more detail.)
9. In the clear Command area, enter a command to be run once the event has cleared.
Commands are built using TALES Expressions. Documented in the Appendix. When the conditions in the
Where clause are met, the command you create runs. The power of this command and where and what you can
run is only limited by the power of the scripts you create and the permissions on the machine where you want
to execute the commands.
This is optional, but could be useful if, for example, you were running an SMS modem separate from your
alerting rules and wanted to send on message in the Command area to send an SMS message if Ping went down,
and then when the Ping Down event was clear, you wanted to send an additional message from the SMS modem
that it is up.
137
UI Commands
10. At this point you use the “Where” area to set the conditions for this Command to be run.
11. In the Add Filter drop down select the filters for your Command.
12. You can filter on the Following Event cases:
• Agent
• Count
• Device Class
• Device Priority
• Event Class Key
• Facility
• Manage
• ntevid
• Priority
• Component
• Device
• Device Groups
• Event Class
• Event State
• IP Address
• Message
• OwnerId
You can add as many conditions as you want to further narrow the cases in which the Command will be ex-
ecuted.
13. Once you have completed setting up the conditions, click the Save button. Now the command is entered and
will run when the conditions are met.
138
Chapter 19. Production States and
Maintenance Windows
1. About Production States and Maintenance Windows
Zenoss has the capability to support “Maintenance Windows” or time periods (either scheduled or on the fly)
where the monitoring and alerting rules are changed. A set of rules governing monitoring, display and alerting can
be collectively defined as “Production States”. When there are temporary changes in Production State, and then a
reversion to the original state, this is a Maintenance Window.
2. Production States
Production State is an important concept in Zenoss. It determines whether or not a device is monitored and can be
used to control several elements of the event system such as whether or not an event will produce a remote alert
(email or page). Typically devices start off their life in state “Pre-Production.” In this state, devices are monitored
by default but no remote alerting occurs and events aren’t shown on the Dashboard. Once a device is in full “Pro-
duction” state monitoring is occurring and remote alerts are sent. If service needs to be performed on a device its
state can be set to “Maintenance” to temporarily block any remote alerts.
There are three factors that affect and define the Production State for devices:
1. Whether or not the device is being monitored.
2. Whether or not you want alerting to occur.
3. Whether or not the device appears on the dashboard.
The available Production States are merely combinations of the above:
• Production - you want all three: monitoring, alerting and dashboard.
• Pre-production - you may want monitoring but not alerting or the appearance of the device notices on the
dashboard
• Test - you may want monitoring and alerting (sent to one email) and but not displaying device info on the
dashboard.
• Maintenance - you want monitoring and collection to occur, and maybe or maybe not the device on the dashboard,
just not alerting occurring
• Decommissioned - no monitoring, no dashboard, no alerting
2.1. Defining Production States for Devices

You can set the Production State for a device or group of device(s) by going to the Edit Tab for the device or device
group and changing the Production State drop-down to whatever state you want the new Production State to be.
The default Production state when you add a device is Production. If you change the Production State for a hierarchy
of devices, the Production state propagates down the hierarchy except when you define an exception to the Production
State further down the hierarchy.
3. Maintenance Windows
Zenoss Maintenance Windows allow scheduled production state changes of a device or all devices in a System,
Group, or Location. Maintenance Windows are defined on the Manage tab of these objects.
139
Production States and Maintenance
Windows
A Maintenance Window has a Start Time, Duration, Repeat Cycle and Start and End Production State. A typical
Maintenance Window changes the Production State to Maintenance at its start, and to Production at its end. The
Start Production State for the Maintenance Window is the state that the monitoring for the device (or group of
devices) is in when the Maintenance Window begins or “opens”. For example, if your device(s) are running along
in a Production State of “Production” (meaning you are monitoring and alerting on the devices normally) and the
Maintenance Window opening time arrives, the Production State changes to the maintenance Window’s Start
Production State.
For example, if the the Start Production State is set to Maintenance, this means you want monitoring and data
collection to continue to occur for the device, but you don’t want alerts to occur or any warnings to appear on the
dashboard. You can use this time to reboot the machine or make configuration changes that would normally create
alerts and not have them actually send alerts. You can either schedule a Maintenance Window or change the Pro-
duction State for the device manually at the time you want to make the changes. When the Maintenance window
closes, the device(s) change to the End Production State for the Maintenance Window. You define the End Production
State for the Maintenance Window. This refers to the Production State that you want the device(s) to revert to
when the Maintenance Window ends. So the Start Production State is the state you want when the Maintenance
Window opens - if I were setting up a Maintenance Window, I would define the window such that when its time
for the Maintenance Window to occur, I want the Start Production State to be Maintenance, and then when the
Maintenance Window time frame expires, I want the Stop Production State to be Production, meaning its back to
monitoring and alerting as normal. This would save sending out known alerts as you rebooted or created other,
known, alerting events.
3.1. Creating and Using Maintenance Windows

You can create a Maintenance Window for an individual device or for any grouping of devices in any hierarchy
you create and define. You can create these windows either for a single device or create a window per device class
or system, and have the window propagate to all devices that fall below where you create the window.
To create a new maintenance window:
1. Navigate to the device or group of devices where you want to define the maintenance window. Open the page
menu and select More and then Administration.
The Administration page appears.
2. From the Maintenance table menu, select Add Maint Window.
The Add Maintenance Window appears.
3. In the ID field enter a name for the maintenance window and click OK.
The name appears in the Maintenance Window list.
4. To define the window, click the name of the Maintenance Window.
The Maintenance Window Status Tab appears.
5. Define the attributes for this Maintenance window.
• Name - Name of the maintenance window.
• Enabled - True or False as to whether you want this maintenance window active.
• Start - The time for the window to become active.
• Duration - The length of time for the window to be in effect starting from the Start time.
• Start Production State - Defines the production state for the window before it opens.
• Stop Production State - Defines the production state for the object once the maintenance window closes.
140
Production States and Maintenance
Windows
6. Click Save.
141
Chapter 20. Reporting
1. About Reporting in Zenoss
Zenoss also excels at aggregating and reporting on data over time for any of the data you have set it up to monitor.
The kinds of Reports that are available include:
• Summary Reports for performance information (CPU, memory, i/o pages, load average, network interface util-
ization)
• Performance threshold summary reports
• Go through the history events and calculate the percentage uptime for device and is components.
• Availability report of any event class
• Ping Issues
• SNMP Issues
• SLA Reporting
• Graphing of trend over time: hourly, weekly, monthly, yearly
• Other Performance Reports
To see the Reports area of Zenoss, from the left navigation click Reports. The Reports organizer list appears.
142
Reporting
Figure 20.1. Report Organizer List
2. Organizing Reports
Reports can be organized just like any other elements in the Zenoss system. You can create categories, sub-categories
and Organizers to organize the reports as you see fit. You can create any kind of hierarchy and relationships the
same way you can do for devices or events.
3. Navigating and Sorting Report Results

Each report result can be sorted by column heading by clicking on the column heading you want to sort by. You
can also sort this report based on any of the column headings or filter based on any keyword you enter in the filter
field.
4. Exporting Reports
You can export any of the included reports in Zenoss by going to the Exporting of Reports as comma separated
value (.csv) files. To export the reports, from the bottom of any of the reports, click the ”Export All” button.
4.1. Add An Export Button to a Report

Adding an Export All button to a report is fairly straightforward. The overall format of the report markup looks
something like this:
<tal:block tal:define="
objects python:here.ZenUsers.getAllThingsForReport();
objects python: (hasattr(request, 'doExport') and list(objects)) or objects;
tableName string: thisIsTheTableName;
batch python:here.ZenTableManager.getBatch(tableName,objects, sortedHeader='getUserid'
);
exportFields python:['getUserid', 'id', 'delay',
'enabled', 'nextActiveNice', 'nextDurationNice',
'repeatNice', 'where'];
143
Reporting
">
<tal:block metal:use-macro="here/reportMacros/macros/exportableReport"> <tal:block metal:fill-slot="report
The normal report markup goes here:
</tal:block>
</tal:block>
</tal:block
The first definition is a call to some method that retrieves the objects for the report. This might be a list, tuple or
an iterable class.
If we are doing an export then we need this to be a list, so the second tal:define line makes sure we have a list in
the event that we are doing an export. It's good to not do this if we are not doing an export. Large reports might
run into performance issues if an iterable is converted to a list unnecessarily.
tablename is defined here for use by the getBatch() call that follows.
exportFields is a list of data to be included in the export. These can be attribute names or names of methods to
call. See DataRoot?.writeExportRows() for more details on what can be included in this list.
Within the <tal:block metal:fill-slot="report"></tal:block> block goes the report markup you would use when not
including the export functionality.
Note: If the Export All button is mysteriously not doing anything you may need to be using zenTableNavigation/mac-
ros/navtool rather than zenTableNavigation/macros/navbody in your report. The former includes the <form> tag,
the latter does not. If you are not providing a <form> tag then you need to use navtool so the export button is
within a form.
5. Reports Included With Zenoss

The basic Report categories (the ones included when you build Zenoss)
5.1. Device Reports

Device Reports aggregate and display data over many devices and device attributes.
• All Monitored Components – The All Monitored components shows all of the components currently being
monitored. This is NOT all components in the system, only the ones that Zenoss is currently collecting perform-
ance data on. The information that appears in this report is: the device name, Component, the type of component
(when available), the description, and the status of each device.
• Model Collection Age – The Model Collection age report shows information about the history of the modeling
that Zenoss does of each device. The information available in this report includes the device name, Device Class,
the time when the device was first seen by Zenoss, the last time Zenoss Collected Data on this device, and any
changes made to the configuration at that time.
• Device Changes - The Device Change report shows information about the history of any changes that Zenoss
detects when modeling each device. This report only shows devices with changes. The information available
in this report includes the device name, Device Class, the time when the device was first seen by Zenoss, the
last time Zenoss Collected Data on this device, and any changes made to the configuration at that time.
• Ping Status issues – The Ping Status Report shows the device name, the device class, the Product name, the
current state of the device and the Ping and SNMP status. The only devices that will show up here are devices
that actually have or have had Ping issues.
144
Reporting
• SNMP Status Issues - The SNMP Status Report shows the device name, the device class, the Product name, the
current state of the device and the Ping and SNMP status. The only devices that will show up here are devices
that actually have or have had SNMP issues.
• New Devices – The New Devices report shows devices that have been recently added. The report shows the
Device Name, the Device Class, when the device was first seen and the model collection age.
• New Devices – The New Devices report shows devices that have been recently added. The report shows the
Device Name, the Device Class, when the device was first seen and the model collection age.
5.2. Event Reports

Event reporting gives you aggregate data about events, event mappings and event classes.
• All Heartbeats – The All Heartbeats Report shows all heartbeats for monitored devices. Heartbeats are reported
by component and number of seconds.
• All Event Classes – The All Event Classes report shows all of the event classes that reside in the Zenoss system.
It also breaks these classes down by SubClasses, the number of instances of that class in the system and the
number of events in the system associated with each Event Class.
• All Event Mappings – The All Event Mappings shows all of the event mappings that you have created
throughout the system. You can sort them by Event Class key, Evaluation or number of events per event class.
5.3. Performance Reports

Performance Reporting allows you to roll up performance data across the Zenoss system.
• Aggregate Reports – The Aggregate reports shows the performance graphs for all of the devices in the system
in graphical format. Common performance stats include PU Usage, Aggregate Free Memory, Aggregate Free
Swap, and Network Output/Input. You can edit the graph parameters by clicking on the graph. You can change
the Width, height, Min Y and Max Y axis. You can also specify which devices are included in the aggregate
and the time span for the graph.
• File System Utilization Report – The File System Utilization Report shows the Total Bytes, used Bytes, Free
Bytes and % Utilization for each device. You can customize the report through the interface for such attributes
and start/end Date and Summary type; either average or Maximum.
• CPU Utilization Report – The CPU Utilization report shows all of the Monitored Interfaces, the list of devices
and the load average and % Utility. You can customize the report through the interface for such attributes and
start/end Date and Summary type; either average or Maximum.
• Threshold Summary – The Threshold Summary Report identifies the devices that approach or exceed their
thresholds and reports them in a list. You can see the device, the component, the event class, count, duration
and percentage. You can filter this list by Event Class or to see all Event Classes, leave the event class Selection
List blank. You can also change the start and end date for the reporting data.
• Availability Report – The Availability Report reports availability of devices in percentage form. You can filter
on device, component, event class or severity. You can also further limit the time frame for the availability.
145
Reporting
• Memory Utilization – The Memory Utilization Report provides system wide information about the memory
usage for devices in the system. This report shows Total memory, Available memory, Cache memory, Buffered
memory, and percent of memory utilized.
5.4. User Reports

User Reports refer to report based on user account information and changes within the Zenoss system.
• Notification Schedules – The Notification Schedules Report shows all of the alerting rules and their associated
details with each one.
6. Graph Reports
Graph Reports allow you to assemble graphs from specific Devices and Device Components into a single report.
Click on Reports in the left navigation menu, then on the Graph Reports organizer to view or create Graph Reports.
Graph Reports have a normal view which is similar to the graph views for Devices and Device Classes. Graph
Reports also have a Printable view more appropriate for printing which can be brought up by clicking on the
Printable button at the top of the report view.
Note that Graph Reports can only display graphs that already exist on Device or Components within Zenoss. You
cannot define new graphs or alter existing graphs from within a Graph Report. If you need this type of functionality
you probably want MultiGraph Reports instead.
Figure 20.2. Graph Report
6.1. Creating a New Graph Report

From within the Graph Reports organizer or a sub-organizer use the Add Graph Report menu item to create a new
report. After entering a name for the new report you will be taken to the edit page. The fields for a Graph Report
are:
• Name - The name of the report is displayed at the top of the report.
• Title - This description is displayed in the list of reports for the report organizer. It is also available for use in
the comments.
146
Reporting
• Number of Columns - This is the number of columns the graphs will be displayed in on the report.
• Comments - The comments are displayed at the top of the Printable version of the report. This is a TALES
evaluated string that may contain html formatting. The variables available to the TALES expression are now
(the current datetime) and report (the report object itself.)
6.2. Adding Graphs

The Add New Graph section of the Edit page allows you to add one or more graphs to the report. The first step is
to select one or more Devices. The list of Devices can be narrowed by entering a search string to the left of the
Filter button and pressing Return or clicking the Filter Button. When you select one or more Devices the Component
list will display the names of all Components defined on at least one of the selected Devices. The Graph list will
list the Graphs available on one or more of the listed Devices. When one or more Components are selected the
Graph list will display Graphs from the selected Components rather than the selected Devices.
At any point you may select one or more Graphs and use the Add Graph to Report button. Zenoss steps through
each selected Component (if any are selected) or Device (if no Components are selected) looking for graphs with
the given names. Matching graphs are added to the Graph Report.
Graph Reports maintain a static list of graphs which does not change when graphs are added or deleted from Per-
formance Templates. For example, take DeviceA which has only one graph called Graph1 and DeviceB which
has two graphs named Graph1 and Graph2. On the Graph Report edit page if you selected DeviceA and DeviceB
the list of graphs would include Graph1 and Graph2. Selecting both graphs and clicking the Add Graph to Report
button would add three graphs to the report: DeviceA's Graph1, DeviceB's Graph1 and DeviceB's Graph2. If at
some later date you created a Graph2 on one of DeviceA's Performance Templates it would not automatically appear
on the Graph Report, you would have to edit the report to specifically add it. Similarly, if one of the graphs was
removed from DeviceB's Template (or if DeviceB was deleted from Zenoss) you would need to manually remove
them from the Graph Report.
147
Reporting
Figure 20.3. Graph Report Edit Page
6.3. Customizing Graph Text

The Graphs section of the Edit page lists the graphs that are included in this report. Click the name of any of the
graphs takes you to an edit page where you can edit the text that appears with the graph when the report is viewed.
The Summary field is displayed above the graph in the normal report view and the Comments field is displayed
to the left of the graph in the printable view. Both of these fields may contain TALES expressions with these
variables: dev (the device), comp (the component) and graph (the graph.)
148
Reporting
Figure 20.4. Graph Report Element
6.4. Organizing Graphs

In both the normal and printed view of the report graphs are laid out from left to right in as many columns as specified
on the report's edit page. For example, if a report has three columns then the first three graphs are placed on the
first line of the report and the fourth graph would be the first one on the second row. By altering the sequence of
the graphs on the edit page you can control where each graph appears on the report view. You change the sequence
by editing the values in the Seq column beside each graph name and choosing the Re-sequence Graphs menu item.
7. MultiGraph Reports
MultiGraph Reports are a powerful mechanism for combining data from different Devices and Components into
a single report. You can create a Graph Definition and have it drawn once for each in a group of Devices and
Components that you define. Alternatively, you can have the data for those graphs combined into a single graph.
The Graph Definitions are very similar to those used in Performance Templates except that these are defined and
used exclusively within a single report. The groups of Devices and Components you assemble are called Collections.
Specifying which Graph Definitions to apply to which Collections is done through Graph Group objects. Like
Graph Reports, MultiGraph Reports have two different views, normal which looks similar to Device and Component
graph pages and printable which is formatted more suitably for printing. The normal view is seen on the Report
tab of any MultiGraph Report. At the top right of that view is a button named Printable for displaying the printable
version.
MultiGraph Reports include their own Graph Definitions and thus do not use the Graph Definitions that are defined
within Performance Templates. If you want to create a report that includes graphs defined on Templates then you
may wish to use GraphReports rather than MultiGraph Reports.
149
Reporting
Figure 20.5. MultiGraph Report Graphs
7.1. Creating A New MultiGraph Report

From within the MultiGraph Reports organizer or a sub-organizer use the Add MultiGraph Report menu item to
create a new report. After entering a name for the new report you will be taken to the edit page. The fields for a
MultiGraph Report are:
• Name - The name of the report is displayed at the top of the report.
• Title - This is displayed at the top of the printable version of the report.
• Number of Columns - The report will display the graphs in this many columns on the report.
Once you've created the MultiGraph Report there are three steps required to get graphs showing on the report:
1. Create a Collection which contains the Devices and/or Components you want to graph.
2. Create a Graph Definition that describes the graph(s) you want on the report.
3. Create a Graph Group which specifies the Collection and the Graph Definition you just created. The Method
setting in the Graph Group lets you choose to have the graph drawn once for each Device/Component in the
Collection or you can have the data from all the Devices/Components combined into a single graph.
150
Reporting
These are just the minimal steps to getting a functional MultiGraph Report. You can create any number of Collec-
tions, Graph Definitions and Graph Groups in a single report. See the sections that follow for details on creating
Collections, Graph Definitions and Graph Groups.
Figure 20.6. MultiGraph Report Edit Page
7.2. Collections
A Collection is a group of Devices and/or Components. A MultiGraph Report must have at least one Collection.
Collections are listed in the Collections table on the report's Edit page. You can create a new Collection with the
Add Collection menu item on that table then specifying a name in the dialog that appears.
A Collection consists of one or more Collection Items. A Collection Item is a list of Device Classes, Systems,
Groups, Locations or specific Devices and Components that should be included in this Collection. You can create
as many Collection Items of the various types as you wish within a single Collection. The controls for creating
Collection Items are in the Add To Collection table of the Collection edit page. The Item Type menu lets you select
one of the following:
• Device Class/System/Group/Location - Selecting one of these options reveals a list of all organizers of that type.
You can select one or more of the organizers to include in the Collection. By selecting True for the Include
Suborganizers field the Collection will also include all organizers recursively beneath the ones you selected.
These Collection Items are dynamic - when devices are added or removed from these organizers they will appear
or disappear from the report. Clicking the Add to Collection button creates a new Collection Item for each of
the selected organizers.
• Specific Device/Component - Selecting this type reveals a list of all Devices in Zenoss. You can use the Filter
field to narrow this list by entering a full or partial Device name. Selecting one or more Devices will display a
list of Component names that apply to one or more of the selected Devices. If you do not select any Components
and click the Add to Collection button then a new Collection Item is created for each selected Device.
Once you have specified an Item Type and made your selection click the Add to Collection button to create the
new Collection Item. It will be added to the list of Collection Items at the end of the page. Collection items can
be deleted or reordered within this list. Order of the Collection Items determines the order that the graphs are drawn
in or the order that data is drawn on a combined graph. See the section on Graph Groups for more details.
151
Reporting
Figure 20.7. MultiGraph Report Collection
7.3. Graph Definitions

Graph Definitions in the context of MultiGraph Reports are very similar to those in Performance Templates. Settings
on the Graph Definition itself define some basic parameters, then you add Graph Points to specify which data
should be drawn. See the section on Graph Definitions in the Performance Chapter for details on creating Graph
Definitions.
The most significant differences between Graph Definitions in the two contexts is how DataPoint Graph Points
and Threshold Graph Points are added. When adding a DataPoint Graph Point to a Graph Definition within a
Performance Template you can select from a list of DataPoints that are defined on that Template. But within the
context of a MultiGraph Report there are no GraphPoint definitions to list. So instead of listing the available
DataPoints, the DataPoint Graph Point dialog has a text field where you enter the name of the DataPoint. To make
things easier the input has an autocomplete feature which knows the names of every DataPoint defined in Zenoss.
This same situation is true with Threshold Graph Points.
152
Reporting
Figure 20.8. MultiGraph Report Graph Definition
7.4. Graph Groups

Graph Groups are used to combine one Graph Definition with one Collection to produce graphs for the report.
You must have at least one Graph Group or your report will have no graphs. You create a new Graph Group by
selecting the Add Group menu item from the Graph Groups table menu. After entering a name for the Graph Group
you are presented with the Graph Group edit page. There are 4 settings on this page:
• Name - This is used to identify the Graph Group on the MultiGraph Report page. It does not appear anywhere
on the actual report.
• Collection - Select one of the Collections that have been defined for this report.
• Graph Definition - Select one of the Graph Definitions that have been defined for this report.
• Method - There are two options for applying the Graph Definition you selected to the Collection that you selected:
* Separate graph for each device: The Graph Definition will be used to draw one graph for each Device and
Component listed in the Collection. The graphs will appear in the list in roughly the same order they are specified
within the Collection. * All devices on a single graph: This draws one graph with the data from all the
Devices/Components on it.
153
Reporting
Figure 20.9. MultiGraph Report Graph Group
7.5. Graph Order

Graph Groups are drawn in the order they are listed on the MultiGraph Report edit page. You can change the order
of the Graph Groups by editing the sequence number next to each then using the Re-Sequence Items menu item
from that table's menu. If a Graph Group results in multiple graphs, the graphs are drawn in the order that the
Collection Items are listed within the corresponding Collection. If a Collection Item specifies a Device organizer
then the order of the Devices drawn from that Collection Item is indeterminate.
As with Graph Reports, if you have specified multiple columns for a report then the graphs are drawn left to right
in that number of columns using as many rows as necessary.
8. Creating Custom Reports

There are a few ways to create reports of your own. You can create some reports through the Zenoss user Interface
or using the Zope management Interface (ZMI).
8.1. Creating Custom Reports Using the ZMI

Zenoss Reports are written in python and templates are available through the Zope Management Interface (ZMI).
To access the ZMI for a particular page, add a /manage to whichever report you are looking at. The ability to create
individual reports is largely dependent on your ability to create python strings to get and display the information.
More details on this will be forthcoming as we add more new reports and create more.
8.2. Create A Custom Device Report Example

Here are the steps for creating a Custom Device Report that will show device name, network address, and device
serial number.
1. From the left navigation menu, select Reports.
2. From the Report Organizers list, click the Device Reports link.
154
Reporting
This is where you will be adding a new report.
3. From the bottom of the page enter a name for this custom report in the Add text box.
4. Click the Add button.
The report you just created will appear in the Report list.
5. Click the name of the new report from the list.
The Report detail page appears.
6. Click the Edit tab to define the report parameters.
7. Fill out the fields for this report as follows.
• Name- The name you want to give to the report.
• Title - The way the report is named in the display. Can be different from the name.
• Path -The path in the hierarchy where the report will be stored.
• Query - The actual query string for If you want to limit the report to just those devices that have a serial
number, you can set the Query value to:
here.hw.serialNumber != ""
• Sort Column - What column you want to use to sort the report.
• Sort Sense - The sense that the system uses to sort (For example asc is ascii)
• Columns These columns are the actual data that be retrieved and displayed in the report.
For example:
getId – would get the name of any devices
getManageIp – would get the IP addresses of the devices
getHWSerialNumber – will grab serial numbers for device.
• Column Names - You can add column names to make the column headers more descriptive.
For the example columns above you could use the column names:
Device
Address
Serial #
NOTE: The information that appears in the fields and how you actually get this information is found in the
admin guide in the Tales Expressions appendix in the Device schema section.
9. Now click the Report tab at the top of the page.
The new device report appears showing the devices that meet the criteria.
155
Reporting
9. Using Reports to Help Troubleshoot Zenoss Daemons

This section will show you how to find and view certain reports that will aid you in troubleshooting Zenoss daemons.
From the Zenoss web interface, navigate to Reports. Follow the path to the various reports listed below to see the
reports. The troubleshooting items on the right give you clues as to what to expect to find in the various reports.
Troubleshooting Items Report Name Where It Lives

zenmodeler issues Model Collection Age /Reports/Device Reports
Any internal Zenoss issues All Heartbeats /Reports/Event Reports/
zendisc errors, adding devices New Devices /Reports/Device Reports
Any alerting rule issues, will show Notification Schedules /Reports/User Reports
all rules in the system
Good summary of snmp status across SNMP Status Issues /Reports/Device Reports
the system including non-monitored
Which devices are monitored and Ping Status Issues /Reports/Device Reports
whether ping is turned on or off
156
Chapter 21. General Zenoss
Administration
1. Working with Zenoss from the Command Line
When working with Zenoss from the command line, you always want to be logged in as the user “zenoss”. If you
log in as root you must become zenoss by issuing the command:
su - zenoss
2. Minimal Zenoss - ZEO and Zope

The Zenoss user interface can run without any other Zenoss processes running. In this mode, only ZEO and Zope
are running.
This mode is useful for troubleshooting many Zenoss issues.
1. Stop all Zenoss processes.

$ zenoss stop
2. Start the zope object database.

$ zeoctl start
3. Start Zope
$ zopectl start
4. Go to the web UI and confirm that you can access the Dashboard.
5. Start the other Zenoss daemons.
3. Checking the Version of Zenoss

You can use the Version tab to check the version of Zenoss and all of the associated components. To access this
information from the Navigation menu in the Dashboard, click Settings. Now click the Versions tab. The Versions
tab appears.
This tab shows the version of the following Zenoss components:
• Zenoss
• Zope
• Database
• Twisted
• OS
• Python
• RRD
157
General Zenoss Administration
• SNMP
This page also gives the Zope uptime.
4. Checking for Zenoss Updates

Use the Settings page Versions tab to check for updates to the Zenoss software. You can have Zenoss to check
daily or click the Check Zenoss Version Now button to check for an update. You can also see the last time a check
for updates was made.
5. Starting and Stopping the Zenoss Daemons

You can use the Zenoss management console to start and stop the Zenoss daemons as well as check the status of
the daemons. To access this information from the Navigation menu in the Dashboard, click Settings tab and then
click the Daemons tab.
Figure 21.1. Settings Page - Daemons Tab
This tab is made up of a list of all of the Zenoss daemons, their process IDs (PIDs), a status indicator and then an
Action area where you can restart a process or stop it. If a daemon is stopped, the Restart button changes to start.
6. Zenoss Daemon Commands and Options

All Zenoss daemons share some similar commands. These commands can be run from the command line for the
device where Zenoss is installed. Each daemon has the following commands:
• run – start daemon but don’t put it into the background. This is good for debugging.
• start – start as a daemon running in the background, detached from the shell.
• stop – stop the daemon.
158
• restart – stop/start the daemon. Sometimes the start command will run before the daemon has terminated. If this
happens just re-run the command.
• status – check the status of a daemon will print out the current process number if running.
• help – display a list of all options for the daemon.
6.1. Configuring Zenoss Daemons

Any daemon can be configured by adding key/value pairs to a file named $ZENHOME/etc/DAEMONNAME.conf.
Valid keys are the long option of any command line option. These can be listed by using the daemons “help”
command.
6.2. General Options for All Daemons

Command Description
-h, --help show this help message and exit
-vLOGSEVERITY,--logseverity=LOGSEVERITY Logging severity threshold
--logpath=LOGPATH override default logging path
-CCONFIGFILE,-- configfile=CONFIGFILE config file
--uid=UID user to become when running default:zenoss
-D, --daemon Become a Unix daemon
--host=HOST hostname of zeo server
--port=PORT port of zeo server
-RDATAROOT, --dataroot=DATAROOT root object for data load (i.e. /zport/dmd)
--cachesize=CACHESIZE in memory cachesize default: 1000
--pcachename=PCACHENAME persistent cache file name default:None
--pcachedir=PCACHEDIR persistent cache file directory
6.3. zenhub Options

Command Description
-x XMLRPCPORT, --xport=XMLRPCPORT Port to listen to for XML RPC calls
--pbport=PBPORT pb port
--passwd=PASSWORDFILE where the password file is stored
6.4. zenmodeler Options

Command Description
--debug don't fork threads for processing
--parallel=PARALLEL number of devices to collect from in parallel
--cycletime=CYCLETIME run collection every x minutes
--ignore=IGNOREPLUGINS Comma separated list of collection maps to ignore
--collect=COLLECTPLUGINS Comma separated list of collection maps to use
-pPATH, --path=PATH start path for collection ie /NetworkDevices
159
Command Description
-dDEVICE, --device=DEVICE fully qualified device name ie: www.zenoss.com
-aCOLLAGE, --collage=COLLAGE do not collect from devices whose collect date is within
this many minutes
--writetries=WRITETRIES number of times to try to write if a read conflict is found
-F, --force force collection of config data (even without change to
the device)
--portscantimeout=PORTSCANTIMEOUT time to wait for connection failures when port scanning
-uUSERNAME, --user=USERNAME Login username
-PPASSWORD, --password=PASSWORD Login password
-tLOGINTRIES, --loginTries=LOGINTRIES number of times to try login
-LLOGINTIMEOUT, --loginTimeout=LOGIN- timeout login expect statements
TIMEOUT
-TCOMMANDTIMEOUT, --commandTimeout=COM- timeout when issuing a command
MANDTIMEOUT
-KKEYPATH, --keyPath=KEYPATH Path to use when looking for keys
-sSEARCHPATH, --searchPath=SEARCHPATH Path to use when looking for commands
-eEXISTENCETEST, --existenceTest=EXISTEN- how to check for command
CETEST
-rPROMPTTIMEOUT, --promptTimeout=PROMPT- timeout when discovering prompt
TIMEOUT
-xLOGINREGEX, --loginRegex=LOGINREGEX regex that will find the login prompt
-wPASSWORDREGEX, --passwordRegex=PASS- regex that will find the password prompt
WORDREGEX
--enable enter enable mode on a cisco device
--termlen enter send terminal length 0 on a cisco device
--enablePause=ENABLEPAUSE time to wait before sending enable command
--enableRegex=ENABLEREGEX regex that will find the enable password prompt
NOTE: --ignore and --collect are mutually exclusive
6.5. zenperfsnmp Options

Command Description
-zZOPEURL, --zopeurl=ZOPEURL XMLRPC url path for performance configuration server
-uZOPEUSERNAME, --zopeusername=ZOPEUSER- username for zope server
NAME
--zopepassword=ZOPEPASSWORD password used to login to the zope server
--zem=ZEM XMLRPC path to an ZenEventManager instance
-dDEVICE, --device=DEVICE Specify a specific device to monitor
--monitor=MONITOR Specify a specific name of the monitor configuration
6.6. zenperfxmlrpc Options

Command Description
160
Command Description
NAME
6.7. zenProcess Options

Command Description
NAME
6.8. zenping Options

Command Description
--configpath=CONFIGPATH path to our monitor config ie: /Monitors/StatusMonit-
ors/localhost
--name=NAME name to use when looking up our record in the dmd de-
faults to our fqdn as returned by getfqdn
--test Run in test mode: doesn't really ping, but reads the list
of IP Addresses that are up from /tmp/testping
6.9. zensyslog Options

Command Description
--statcycle=STATCYCLE Number of seconds between the writing of stats
--dmdpath=DMDPATH zope path to our dmd /zport/dmd
--parsehost try to parse the hostname part of a syslog HEADER
--stats print stats to log every 2 secs
--logorig log the original message
--debug debug mode no threads
--minpriority=MINPRIORITY Minimum priority that syslog will accept
--heartbeat=HEARTBEAT Number of seconds between heartbeats
--syslogport=SYSLOGPORT Port number to use for syslog events
6.10. zenstatus Options

Command Description
--configpath=CONFIGPATH path to our monitor config ie: /Devices/Server
161
Command Description
--parallel=PARALLEL number of devices to collect at one time
--cycletime=CYCLETIME check events every cycletime seconds
6.11. zenactions Options

Command Description
--cycletime=CYCLETIME check events every cycletime seconds
--fromaddr=FROMADDR address from which email is sent
--zopeurl=ZOPEURL http path to the root of the zope server
6.12. zentrap Options

Command Description
--statcycle=STATCYCLE Number of seconds between the writing of stats
-tTRAPPORT, --trapport=TRAPPORT Port number for listening for traps
6.13. zencommand Options

Command Description
NAME
--parallel=PARALLEL number of devices to collect at one time
7. Troubleshooting Zenoss Daemons

When Zenoss is having an issue, it will write stack traces into its log files. These log files are important for deci-
phering exactly what went wrong with the application. This section demonstrates how to generate a stack trace.
This will generate a stack trace where you can see errors in the log.
1. While logged in as the zenoss user, stop all zenoss processes.
2. Shut Down MySQL.

$ sudo service mysqld stop
3. Start the Zope Object Database.

$ zeoctl start
4. Run zenperfsnmp in the foreground in debug mode.

$ zenperfsnmp run
5. Notice there are stack traces saying that the daemon can’t connect to zenoss.
162
6. Start Zope.
$ zopectl start
7. Go to dashboard and see the error message “Lost connection to Zenoss”. This error on the dashboard can appear
for many reasons related to the loss of connectivity or some back end failure of the system.
8. Look for a more useful error in the zope log file $ZENHOME/log/event.log.
9. Restart mysqld.
$ sudo service mysqld start
10. Restart Zenoss.

$ zenoss start
11. Look at the end of all zenoss log files for any errors.
$ tail $ZENHOME/log/*.log | less
8. Automatic Startup in Linux Environments

Zenoss can be controlled entirely by the bin/zenoss script. To provide automatic startup in Linux environments,
you must link Zenoss to the /etc/rc.d/init.d directory
$ ln -s $ZENHOME/bin/zenoss /etc/rc.d/init.d
It is important to either add $ZENHOME to the root environment or to the zenoss script itself.
9. Using Zenoss with a Remote MySQL Instance

If you are interested in using a remote MySQL database for Zenoss, set it up the same way you would set it up if
you were using a native database. Then log into the management console.
1. First change the database address for the Backend Type for the mysql database.
From the Zenoss Dashboard, in the Navigational menu, select Event Manager.
The ZenEventManager page appears.
2. Change the Hostname field to the address of the MySQL database you want to use.
3. Restart Zenoss.
The MySQL database you entered is now the default database.
10. Registering MIBs with Zenoss

The MIB loader is called zenmib. To load MIBs, first copy them to $ZENHOME/share/mibs/site. Then run zenmib
using the command:
zenmib run mibfile
163
10.1. Resolving MIB Dependencies

You loaded aaa.mib, and when you attempt to load bbb.mib, you get this error:
INFO:zen.zenmib:Unable to find a file providing the MIB AAA-MIB
To resolve the dependency, load them like this

zenmib run aaa.mib bbb.mib
164
Chapter 22. Backup, Recovery and
Maintenance
1. Backup and Restore
Zenoss provides tools to backup the configuration and data from a Zenoss install and restore that information later.
This can be useful in taking periodic snapshots of your install for backup purposes, moving your data from one
Zenoss installation to another or restoring your setup and performing a fresh install of Zenoss. These are the spe-
cific items that are included in the backup and restore:
• The entire events database in mysql.
• The Zope database, which includes all devices, users, event mappings, etc.
• The $ZENHOME/etc directory, which contains config files for the zenoss daemons.
• The $ZENHOME/perf directory, which contains performance data,
The sections below describe in detail the backup and restore scripts and the options for controlling their behavior.
Typical use of zenbackup looks like:
> zenbackup --save-mysql-access --file=BACKUPFILEPATH
Typical use of zenrestore looks like:

> zenrestore --file=BACKUPFILEPATH
Suggestions for a satisfying backup/restore experience:
• If you have the available disk space, tar and zip $ZENHOME before starting any backup or restore operation.
This gives you a chance to recover in case something goes awry.
• Make sure Zenoss, including all daemons, is stopped before performing a restore.
• Using these tools to go from a newer version of Zenoss to an older version could be bad news and should
really be avoided.
• If you use these tools to go from an older version of Zenoss to a newer version you should run zenmigrate
after the restore.
• If restoring to a different zenoss installation than the backup is initially from, make sure file paths in the
$ZENHOME/etc/*.conf files are appropriate for the new environment after you restore.
1.1. Backup Details

The script for backup is $ZENHOME/bin/zenbackup. If zenoss is running then you can run zenbackup without
any arguments and a backup file will be placed in $ZENHOME/backups. zenbackup --help will give a full list of
the available options. Some of the more interesting options are:
--dbname
This is the name of the mysql database zenoss uses to hold event data. By default this is "zenoss" but this can be
specified when zenoss is installed. This value can be seen by looking at the database field on the Event Manager
165
Backup, Recovery and Maintenance
page in zenoss. If you don't specify --dbname then zenbackup will attempt to retrieve this information from zeo
unless you specify --dont-fetch-args.
--dbuser, --dbpassword
These are the mysql username/password used to access the events database. If you don't specify --dbuser or --db-
password then zenbackup will attempt to retrieve this information from zeo unless you specify --dont-fetch-args.
--dont-fetch-args
This instructs zenbackup not to attempt to get values for dbname, dbuser and dbpassword from zeo.
--file=FILE
Use --file to specify a location for the backup file. By default it will be named zenoss_<DATE>.tgz and placed in
$ZENHOME/backups.
--stdout
This flag tells zenbackup to send send the backup information to stdout instead of to a file. Incompatible with --
verbose.
--save-mysql-access
This instructs zenbackup to save dbname, dbuser and dbpassword as part of the backup file so that zenrestore will
have this information during a restore operation. Use this with caution as it means your backup files will contain
a mysql username and password.
--no-eventsdb
Do not include the mysql events database as part of the backup.
-v, --verbose
Print progress messages. Incompatible with --stdout.
1.2. Restore Details

The script for restoring zenoss from a backup is $ZENHOME/zenrestore. Make sure that zenoss is stopped before
performing a restore. If you used the --save-mysql-access option when you created the backup file then you only
need to specify --file when you run zenrestore. Otherwise you need to specify dbname, dbuser and dbpassword
also.
--file
This is a backup file created with zenbackup You must specify either --file or --dir.
--dir
The path to an unzipped backup file. You must specify either --file or --dir.
--dbname
This is the name of the mysql database zenoss uses to hold event data. This database must exist before zenrestore
is run. If there are any zenoss tables in the database they will be dropped by zenrestore before it restores the
backedup tables and data. If you use a different dbname than was in use when the backup was created then after
the restore you'll need to set the database name on the Event Manager page.
--dbuser, --dbpassword
166
Backup, Recovery and Maintenance
These are the mysql username/password used to access the events database. If you don't specify --dbuser or --db-
password then zenrestore will attempt to use values stored in the backup file if --save-mysql-access was used in
creating it.
--no-eventsdb
Do not restore the mysql events database. If the backup file does not contain mysql events data then zenrestore
will not modify your events database even if you do not specify --no-eventsdb.
-v, --verbose
Print progress messages.
1.3. Periodic Backups

Backing up your Zenoss data and configuration is a very good idea. $ZENHOME/bin/zenbackup can create backups
that include your zeo database (devices, etc), RRD files (performance data), MySQL tables (events) and your
Zenoss configuration files. See section **** for information on using zenbackup and zenrestore.
1.3.1. Pack ZEO Database

The Zeo database needs to be packed periodically to reclaim space. To do this you should set up a cron job that
runs the following command weekly:
$ZENHOME/bin/zeopack.py -p 8100
1.3.2. Log Rotate Script

If your system uses logrotate to manage files put the following in /etc/logrotate.d/zenoss to manage Zenoss’ log
files:
/usr/local/zenoss/log/*.log {
weekly
rotate 2
copytruncate
}
1.3.3. Backing up the MySQL Event Backend

MySQL should be backed up following the MySQL manual.
167
Chapter 23. ZenPacks
1. About Zenpacks
A ZenPack is a package that adds new functionality to the Zenoss Core. A ZenPack may add Action Rules, Event
Classes, Event Commands, User Commands, Service Classes, Data Sources, Graphs, Performance Templates,
Reports, Model Extensions or Product Definitions. A ZenPack may also add new daemons and new UI features
such as menus.
1.1. Installing ZenPacks

The command to install a ZenPack from the command line is:
zenpack run --install filename
This unzips the ZenPack file into $ZENHOME/Products/<ZenPackId> and installs the ZenPack in Zenoss.
1.2. Creating a ZenPack

When logged into Zenoss as an Administrator click on the Setting link and then on the ZenPacks tab. Select the
"Create a ZenPack..." menu item. You will get a dialog asking for your zenpack id as well as other info. Click
save. This creates both the ZenPack object in the database as well as a new directory in the filesystem $ZEN-
HOME/Products/<your zenpack id>.
There are two methods for adding items to a ZenPack. To add Device Class, Event Mappings and other zeo database
objects you select them in the Zenoss UI and use the "Add to ZenPack" menu item. Not all types of objects can
be added to ZenPacks, for example Devices themselves cannot be added to a ZenPack. By clicking on Settings,
then on the ZenPacks tab you can see a list of installed ZenPacks which should include the one you just created.
By clicking any of these links you can see a list of the objects linked to that ZenPack.
ZenPacks can contain items that are not zeo database items, such as new daemons, Data Source types, skins, etc.
These are added to a zenpack by placing them in the appropriate subdirectory within the ZenPack's directory. See
the HelloWorldZenPack for details on these subdirectories.
You create the actual .zip file that is an installable ZenPack by clicking the Export button the the ZenPack's page
(Settings/ZenPacks/YourZenPack.) This does two things. First it exports the objects in the database into an xml
file in your ZenPack's objects subdirectory. Second it zips your ZenPack and places it in $ZENHOME/eport/YourZen-
Pack.zip. Alternatively, you can zip your ZenPack manually using the zip utility or the $ZENHOME/bin/zipzenpack
script as long as your objects/objects.xml database export file does not need to be updated.
1.3. Example ZenPack

HelloWorldZenPack is an example ZenPack and a good starting point for creating your own ZenPacks. The code
and comments in its files provide more detail as to the workings of the install process and other aspects of ZenPacks.
HelloWorldZenPack and other Community ZenPacks are available at http://www.zenoss.com/download/links.
1.4. ZenPack Structure

Using HelloWorldZenPack as a model, this section describes the structure and features of a ZenPack.
1.4.1. HelloWorldZenPack/
In the top level directory of our ZenPack contains our Model Extensions, this would be the Python code that may
extend the existing object model in any way. In this example, we have two files, init.py and HelloWorld.py. You
are not required to have an init.py file or any other files at this level. You are also not restricted to any particular
number of files.
168
ZenPacks
1.4.2. HelloWorldZenPack/init.py
Just like in a Python module, init.py contains any initialization code for your ZenPack.
1.4.3. HelloWorldZenPack/HelloWorld.py
Includes some example Model Extensions, which illustrates the implementation of new objects with attributes and
relationships. In the file, Device, Group, Location, Admin classes are defined. Each class has an attribute and some
sort of relationship with one another.
1.4.4. HelloWorldZenPack/daemons
This directory should exist in the ZenPack however this directory may be left empty. This directory contains bin-
aries which represent additional daemons for Zenoss.
Once the ZenPack is installed the daemon will be started during a zenoss start.
1.4.5. HelloWorldZenPack/datasources
Classes in this directory are subclasses of ZenModel.RRDDataSource.RRDDataSource and provide new types of
data sources which are made available within the Zenoss UI.
1.4.6. HelloWorldZenPack/modeler
This directory should exist in the ZenPack however this directory may be left empty.
1.4.7. HelloWorldZenPack/objects
This directory should exist in the ZenPack however this directory may be left empty. This directory contains xml
files to be imported into the ZeoDB. When imported a object will be instantiated based on the data in the xml files.
Each xml may contain one or many object definitions.
In the directory, we have example for an EventClass, EventClassInst, EventCommand, ServiceClass, RRDTemplate,
and UserCommand. These objects may be any object you wish to export from an existing Zenoss core. (see How
do I export objects to xml?)
1.4.8. HelloWorldZenPack/skins
This directory should exist in the ZenPack however this directory may be left empty. This directory contains page
templates that add new UI to Zenoss.
The "skins" directory will be registered as a Directory View and acts like other "skins" directories within $ZEN-
HOME/Products directory.
1.5. Removing a ZenPack

Warning: Removing a ZenPack can have unexpected consequences. For example, removing a ZenPack that installed
a Device Class will remove both the Device Class and all Devices within that class. For this reason you should
always perform a backup before removing ZenPacks. The command to remove a ZenPack is:
zenpack --remove <ZenPack id>
2. ZenJMX
2.1. About ZenJMX
ZenJMX is a ZenPack that allows Zenoss to communicate with remote JMX agents. The ZenJMX ZenPack intro-
duces a data source of type ' JMX' . A ' JMX' data source allows you to define which JMX attributes should be
169
ZenPacks
monitored by Zenoss, as well as which operations you wish Zenoss to invoke. The ZenPack also introduces the
zenjmx daemon, which is used to perform the actual retrieval of data from a JMX agent.
2.2. JMX Background

Java Management Extensions (JMX) are used throughout the Java Virtual Machine to provide performance and
management information to clients. Using a combination of JConsole (Sunâ s JMX client that is shipped with the
JDK) and JMX, a system operator can examine the number of threads that are active in the JVM or change the log
level. There are numerous other performance metrics that can be gleaned from the JVM, as well as several man-
agement interfaces that can be invoked that change the behavior of the JVM.
In Java 5 Sun introduced the â Remote API for Java Management Extensions. This enhancement defines an RMI
wrapper around a JMX agent and allows for independent client development. ZenJMX accesses remote JMX
agents via the "Remote API for Java Management Extensions". It currently does not support local connections
(provided via the temporary directory) to JMX Agents.
2.3. ZenJMX Capabilities

ZenJMX is a full-featured JMX client that works out-of-the-box with JMX agents that have their remote APIs
enabled. It supports authenticated and unauthenticated connections, and it can retrieve single-value attributes,
multi-value attributes, and the results of invoking an operation. Operations with parameters are also supported so
long as the parameters are primitive types (Strings, booleans, numbers). Multi-value responses from operations
(Maps and Lists) are supported, as are primitive responses from operations.
The "JMX" Data Source installed by ZenJMX allows you to define the connection, authentication, and retrieval
information you wish to use in order to retrieve performance information. The IP address is extracted from the
parent device, but the port number of the JMX Agent is configurable in each data source. This allows you to operate
multiple JMX Agents on a single device and retrieve performance information for each agent separately. This is
commonly used on production servers that run multiple applications.
Authentication information is also associated with each JMX Data Source. This offers the most flexibility for site
administrators because they can run some JMX agents in an open unauthenticated fashion and some JMX agents
in a hardened and authenticated fashion. SSL wrapped connections are supported by the underlying JMX Remote
subsystem built into the JDK but they were not tested in the Zenoss labs. As a result, your success with SSL en-
crypted access to JMX Agents may vary.
The Data Source allows you to define the type of performance information you wish to achieve: single-value at-
tribute, multi-value attribute, or operation invocation. Each is described in detail in following sections. To specify
the type of retrieval you'll need to either specify an attribute name (and multiple or a single data point) or you'll
need to provide operation information.
Any numerical value returned by a JMX agent can be retrieved by Zenoss and graphed and checked against
thresholds. Non-numerical values (Strings and complex types) cannot be retrieved and stored by Zenoss.
Tread carefully when selecting the data point type. Many JMX Agent implementations use inconsistent nomenclature
when describing attributes. In some cases the term "Count" refers to an ever-increasing number (a "Counter" data
point type). In other cases the term "Count" refers to a snapshot number (a "Gauge" data point type). Make sure
you understand the semantics of the attribute name and choose the proper Zenoss data point type when you set up
your data point.
2.4. Single Value Attribute Calls

This is the most basic usage scenario. If you are interested in retrieving a single value from an MBean in a JMX
Agent you fall into the "single value attribute" category. To define a single-value attribute call simply provide the
fully qualified name of your MBean and then provide the name of the attribute in the "Attribute Name" field of
the data source. Lastly, you must define a data point that has the same name as the "Attribute Name" you previously
defined.
170
ZenPacks
Zenoss recognizes a single value attribute mode when you have only 1 data point and it's name matches the Attribute
Name defined in the data source. Some examples of this include the commonly referenced JDK Threading inform-
ation:
• MBean Name: java.lang:type=Threading
• Attribute Name: ThreadCount
• Data Points:
• ThreadCount (type: counter)
Java uses lots of file descriptors during normal operation. The number of open file descriptors the JVM is working
with can be measured using the following information:
• MBean Name: java.lang:type=OperatingSystem
• Attribute Name: OpenFileDescriptorCount
• Data Points:
• OpenFileDescriptorCount (type: gauge)
There are several other single-value attributes that can be retrieved from the JDK. We recommend using JConsole
to interactively navigate through the MBean hierarchy to determine which MBeans contain useful information to
you. See the "Interrogating an JMX Agent via JConsole" section for additional information on how to inspect the
MBeans deployed in an JMX Agent.
2.5. Multi-Value Attribute Calls

If your MBean attribute defines multiple subattributes that you are interested in capturing you fall into the category
of a "multi-value attribute" call. The JDK contains a few multi-value attributes you might be interested in capturing,
including garbage collection statistics that were captured during the copy and mark-sweep compact collection
cycles.
The JDK also provides heap memory information via a multi-value attribute. The amount of committed, used, and
maximum heap memory can be viewed by setting up a multi-value attribute in Zenoss with the following inform-
ation:
• MBean Name: java.lang:type=Memory
• Attribute Name: HeapMemoryUsage
• Data Points:
• committed (type: gauge)
• used (type: gauge)
• max (type: gauge)
2.6. Operation Calls

Some management values need to be computed. These situations frequently arise when custom MBeans are deployed
alongside an enterprise application. An MBean named "Accounting" might be deployed within an enterprise ap-
plication that defines operations intended for operators or support staff. These operations might include methods
such as "getBankBalance()" or "countTotalDeposits()".
ZenJMX has the ability to invoke operations, but there are some subtleties in how ZenJMX sends parameters to
the JMX Agent and interprets the response.
171
ZenPacks
2.6.1. Operation Calls: Scenario #1-No parameters, single return value

In the most basic usage scenario no arguments are passed to the operation and a single value is returned. This usage
scenario is very similar to a single-value attribute call, except we're invoking an operation to retrieve the value
rather than accessing an attribute. The configuration for this hypothetical usage scenario follows:
• MBean Name: Application:Name=Accounting,Type=Accounting
• Operation Name: getBankBalance()
• Data Points:
• balance (type: gauge)
2.6.2. Operation Calls: Scenario #2-No parameters, multiple values returned in

List format
In this scenario no parameters are passed to an operation, but multiple response values are provided in a List. The
values returned are expressed in a List<Object>, but they are coerced (but not casted) to doubles prior to being
stored in Zenoss. This means that returning a numeric value as "1234" will work, but "1,234" will not work. The
litmus test is to evaluate if Double.valueOf(object.toString()) will successfully evaluate.
ZenJMX can be configured to read multiple values from an operation's results by defining multiple data points.
You must define a data point for each value returned from the operation, and if there is a mismatch between the
number of data points you define and the size of the List<Object> returned an exception will be generated. The
configuration for ZenJMX follows:
• Operation Name: getBalanceSummary()
• Data Points:
• dailyBalance (type: gauge)
• annualBalance (type: gauge)
2.6.3. Operation Calls: Scenario #3-No parameters, multiple values returned in

Map format
In this scenario no parameters are passed to an operation, but multiple response values are provided in a Map<String,
Object>. The keyset of the Map contains the names of data points that can be defined, and the values are the values
of said data points. When a Map<String, Object> is returned you need not capture all of the returned values as
data points, and you can instead pick the exact values you are interested in. To choose the values to capture you
simply define data points with the same names as Strings in the keyset.
The following configuration demonstrates how to extract specific data points from an operation that returns a
Map<String, Object>. The key item to note in this configuration is that "dailyBalance" and"annualBalance" must
be present as keys in the returned Map<String, Object> and their values must be coercable via the
Double.valueOf(object.toString()) idiom.
• Operation Name: getBalances()
• Data Points:
• dailyBalance (type: gauge)
• annualBalance (type: gauge)
172
ZenPacks
2.6.4. Operation Calls: Scenario #4-Single parameter in polymorphic operation

MBeans are implemented as Java classes and Java permits parameterized polymorphic behavior. This means that
multiple methods can be defined with the same name so long as their parameter signatures differ. You can safely
define "getBalance(String)" and "getBalance()" and the two exist as separate methods.
In order to properly resolve methods with the same name the caller must provide a Class[] that lists the types of
parameters that exist in the method's signature. This resolves the candidate methods to an individual method which
can then be invoked by passing an Object[].
ZenJMX allows you to resolve methods of the same name and asks you to provide the fully qualified class names
of each parameter in comma delimited format when you set up the data source. Note that primitive types (String,
Boolean, Integer, Float) are supported but complex types are not supported, and that you must include the class'
package name when providing the information (java.lang.String).
The Object[] of parameter values must line up with Class[] of parameter types, and if there is a mismatch in the
number of types and values that are provided an exception will be generated.
The marshaling of values from String to Boolean, Integer, and Float types is provided via the .valueOf() static
method on each of those types. That is, if you define an attribute of type java.lang.Integer you must provide a
String that can be successfully passed to java.lang.Integer.fromValue(). If you fail to do so an exception is generated.
This example illustrates how to pass a single parameter to a polymorphic operation:
• Parmaeter Types: java.lang.Integer
• Parameter Values: 1234
• Data Points:
Here's another example where we've changed the type of the parameter passed to the method to be a String. Se-
mantically it represents a different type of Account in our example:
• Parmaeter Types: java.lang.String
• Parameter Values: sbb552349999
• Data Points:
2.6.5. Scenario #5: Multiple parameters in polymorphic operations

The above example describes how polymorphic behavior in Java functions and how method resolution can be
provided by identifying the Class[] that represents the parameters passed to a method. The situation where multiple
parameters are passed to a polymorphic operation is no different then the situation where a single parameter is
passed to a polymorphic operation, except that the length of the Class[] and Object[] is > 1.
When multiple parameters are required to invoke an operation you must provide the fully qualified class names
of each parameter's type in comma delimited format, as well as the object values for each type (also in comma
delimited format).
173
ZenPacks
The following example demonstrates a configuration that passes 2 parameters to an MBean operation. The second
parameter passed is a default value to return if no account can be located matching the first parameter.
• Parmaeter Types: java.lang.String, java.lang.Integer
• Parameter Values: sbb552349999, 0
• Data Points:
There are additional combinations that are possible with polymorphic methods and the values they return, and
those combinations are left as an exercise for the reader to explore. The logic for extracting results from multi-
value operation invocations follows the same rules as the logic for extracting results from a multi-value attribute
read. For additional information on the rules of that logic see the section above on multi-value attributes.
2.7. ZenJMX Behavior

The ZenJMX ZenPack defines a data source named "JMX" that allows you to query any single or multi-value at-
tribute, or invoke an MBean operation. It also comes with a built-in template named "Java" that contains MBean
information for a few beans built into the JVM.
When the "zenjmx" daemon is started it communicates with ZenHub using XML-RPC. It retrieves a list of devices
that possess "JMX" data sources, and asynchronously issues queries to each of those devices. Processing of the
responses is handled asynchronously as well.
The asynchronous behavior of the zenjmx daemon is achieved through the J2SE 5.0 Concurrency APIs documented
in java.util.concurrent. Unlike Twisted, these APIs are thread-centric. Zenjmx is a multi-threaded application where
an individual thread is created for each request to a JMX agent. Another thread is created to asynchronously process
the result.
The timeout for each individual JMX call is configurable via the "jmxTimeOut" property in ${ZENHOME}/etc/zen-
jmx.conf. You can also control the thread pool size used when dispatching queries to agents by adjusting the
"jmxPoolSize" property. By adjusting the jmxPoolSize property you control how many outstanding requests can
be in-flight at any given time.
ZenJMX will attempt to use as many of the threads in the pool as possible, and will eventually block and wait
until a thread is free before dispatching another request. That is, if the jmxPoolSize is set to 10 and there are currently
10 outstanding requests, the call to issue the 11th request will block until either 1 of the 10 outstanding requests
returns or until the jmxTimeOut expires on 1 of the 10 outstanding requests and the thread is freed.
You should adjust the jmxPoolSize and jmxTimeOut values based upon your operating environment. In large java-
centric facilities where a lot of Zenoss host resources can be devoted to running zenjmx you may consider increasing
the jmxPoolSize to a very large value in order to reduce your cycle time. If you are confident that your network
connectivity to your JMX Agents is strong, and the hosts on which your JMX Agents reside are fast, you may
consider reducing the jmxTimeOut to a smaller value. By doing so you reduce your cycle time, but you also run
into the potential problem of losing data that just took a long time to return to you.
Please note that ZenJMX periodically "injects" a collection cycle into the reactor. These injections occur on a
regular periodic basis that is based on the snmp cycle time of the performance collector zenjmx is associated with,
or on the value read from the cycleTime property defined in ${ZENHOME}/etc/zenjmx.conf. The injection process
is an asynchronous and scheduled event it will occur on a regular basis even if the JMX dipatcher thread pool is
filled with in-flight queries.
You can get yourself into a bit of a jam if you monkey around with the cycleTime and jmxTimeOut values too
much. You want to avoid setting the cycleTime to be lower than the jmxTimeOut. If you set the cycleTime to be
174
ZenPacks
lower than the jmxTimeOut, and if you have JMX Agents on the network that are slow to respond, you can get
zenjmx into an ever-increasing resource constraint as more and more JMX request threads will be occupied servicing
queries from previous cycles. As a result we highly recommend setting the cycleTime to be greater than the jmx-
TimeOut.
After zenjmx retrieves information from a JMX agent it sends an XML-RPC request to ZenHub to store the per-
formance information. This asynchronous operation occurs for each value read from a JMX Agent.
Lastly, ZenJMX heartbeats after each collect cycle via XML-RPC to ZenHub to let Zenoss know that ZenJMX is
still alive and well.
2.8. Running the ZenJMX Daemon

The zenjmx daemon can be started by running "${ZENHOME}/bin/zenjmx start". Output from zenjmx is logged
to ${ZENHOME}/log/zenjmx.log". ZenJMX uses Apache's Log4J for logging, and the verbosity in the logfile
can be dramatically reduced by adjusting the log4j.properties file stored in ${ZENHOME}/Products/ZenJMX.
You can also set up the LOGFILE appender in log4j.properties to use a rolling logfile rather than a continuously
appended logfile. See the Apache Log4J documentation on how to perform that task.
You can also run zenjmx in the foreground by running "${ZENHOME}/bin/zenjmx run". Additional parameters
(such as --cycle or --cycleTime) can be provided after the "run" or "start" command. This is consistent with how
other Zenoss daemons behave.
Most users will want to start the ZenJMX daemon in the background using the "${ZENHOME}/bin/zenjmx start"
command and immediately follow that up with "tail -f ${ZENHOME}/log/zenjmx.log" to see what ZenJMX is
doing. Debugging mode is enabled by default and results in the printing of aggregate collection statistics across
multiple cycles. This gives you an idea of how successful (or unsuccessful) ZenJMX has been at collecting values
from JMX Agents.
2.9. Defining Custom JMX Data Sources

Custom JMX Data Sources allow system administrators to monitor any attribute or operation result accessible via
a JMX call. ZenJMX creates a "JMX" Data Source and allows you to provide Object information, as well as au-
thentication settings, and attribute/operation information. Determining which object and attribute names, as well
as which operations to invoke, is the key to customizing ZenJMX.
Start off by creating a new Performance template at the /Device level. The performance templates associated with
a device are accessible viathe More->Templates link when looking at a device's page. Click the second down arrow
and select "Add Template". Provide a descriptive name for the template, such as "JVM Values". After the template
is created click on it. You should now be looking at the "JVM Values" performance template.
Click the down arrow next to Data Sources and select "Add Data Source". Provide a descriptive name of the JMX
value you wish to retrieve. In our case we are interested in memory inforamtion so set the ID to "Heap Memory".
Set the Type to JMX.
Enter the JMX Management Port (note: this is NOT necessarily the same as the listen port for your server!) and
Object Name. The Object Name is also referred to as the MBean name. Enter "java.lang:type=Memory" as the
Object Name. If your JMX Agent requires authentication provide the username and password.
Enter "HeapMemoryUsage" as the Attribute Name. Then add gauge data 425 points named "committed", "max",
and "used". Click Save.
Lastly, add graphs that reference these new data points. Unfortunately ZenJMX will either need to be restarted in
order to find out about your newly added data source, or you will need to wait for the configCycleTime to expire.
Most performance collectors have a configCycleTime set to 60 minutes, meaning ZenJMX will check in every 60
minutes to get a list of updated JMX data sources and devices.
Please review "Interrogating an JMX Agent via JConsole" to learn how to determine the object name, attribute
name, and data points that might be interesting in your application.
175
ZenPacks
2.10. Enabling Remote JMX Access

Each application server has a slightly different process for enabling remote JMX Access. It's best to consult with
your application server for specific instructions. We've included instructions for a few commonly used configurations
below.
2.10.1. Remote JMX Access for the standard JVM

The JAVA_OPTS environment variable can be used to enable remote access to JVM MBeans. Set it as follows:
JAVA_OPTS="-Dcom.sun.management.jmxremote.port=12345
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote.ssl=false"
export JAVA_OPTS
When starting an application pass the JAVA_OPTS variable as an argument to the JVM as follows:
java ${JAVA_OPTS} -classpath /path/to/your/application.jar com.yourcompany.Main
You can then use JConsole to connect to localhost:12345. Authentication can be configured by modifying the
java.security file as well as java.policy. There are lots of examples available on the Internet that can provide
guidance in how to achieve authenticated remote access to JVM MBeans.
2.10.2. Remote JMX Access for Tomcat

The same JAVA_OPTS approach can be used to enable remote access to Tomcat MBeans. Set the JAVA_OPTS
variable as illustrated above and then execute the "./catalina.sh start" command in ${TOMCAT_HOME}/bin.
Note that Tomcat 6.0.14's catalina.sh does not process the "stop" command properly when the JAVA_OPTS
variable is set. We recommend using 2 separate shells when troubleshooting JMX problems in Tomcat: one for
starting Tomcat (with the JAVA_OPTS variable set) and a different one for stopping Tomcat (where the
JAVA_OPTS variable is not set).
2.10.3. Remote JMX Access for JBoss

JBoss uses the JAVA_OPTS approach for enabling remote access to beans. However, it requires some additional
properties. To set up your JAVA_OPTS for use in JBoss see the following code segment:
JAVA_OPTS="-Dcom.sun.management.jmxremote.port=12345"
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="${JAVA_OPTS} -Djboss.platform.mbeanserver"
JAVA_OPTS="${JAVA_OPTS} -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderI
export JAVA_OPTS
When you start JBoss via the run.sh you must also pass the "-b 0.0.0.0" argument:
cd ${JBOSS_HOME}/bin
./run.sh -b 0.0.0.0
JMX actually uses 2 separate ports for MBean access: one is used for initial connection handling and authentication,
and the other is used for RMI access. During the handshake between a JMX Client and the JMX Agent the agent
tells the client the IP address and port number for the RMI registry. By default JBoss sets the IP address to 127.0.0.1.
This works when the JMX client and the JMX agent reside on the same device, but it won't work in a distributed
environment.
By passing the "-b 0.0.0.0" argument you instruct JBoss to bind to all available network ports, and this results in
the JMX Agent's handshaking logic using a network reachable address when informing clients of the RMI registry
hostname and port.
176
ZenPacks
2.10.4. Remote JMX Access for WebLogic

JSR-160 standardized remote access to JMX Agents, and allows for any client to connect to an JMX Agent using
classes packaged with the JDK. WebLogic versions prior to 9.0 required clients to use a WebLogic JMX client
library that used a proprietary protocol to interact with the JMX Agent. You'll need to make sure you're running
WebLogic 9.0 or higher in order to monitor it via ZenJMX.
If you're new to WebLogic and have not set up a domain and server you'll need to run the startWLS.sh script located
in ${BEA_HOME}/wlserver_10.0/server/bin. If you don't have the Terminal I/O package installed you can set
the JAVA_OPTIONS variable to the following value:
JAVA_OPTIONS="-Dweblogic.management.allowPasswordEcho=true"
export JAVA_OPTIONS
Provide a username and password to start WebLogic. Note that WebLogic requires a password that is at least 8
characters long. Wait for WebLogic to generate a configuration and start up. Shut down WebLogic and restart it
with remote JMX access enabled.
To enable remote JMX acess set the following variable:

JAVA_OPTIONS="-Dcom.sun.management.jmxremote.port=12347"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.ssl=false"
export JAVA_OPTIONS
Then re-run the ./startWLS.sh script. JConsole can then communicate with the server on port 12347.
2.11. Interrogating an JMX Agent via JConsole

JConsole is a tool built into the JDK that allows system administrators to interrogate a JMX Agent and examine
the MBeans deployed within the server. JConsole also allows administrators to view JVM summary information,
including the amount of time the JVM has been running, how many threads are active, how much memory is cur-
rently used by the heap, how many classes are currently loaded, and how much physical memory exists on the
machine.
JConsole also provides a graph that shows memory, thread, and class usage over time. The scale of the graph can
be adjusted so that a system administrator can examine a specific period of time, or can zoom out to view a longer
range picture of usage. Unfortunately, JConsole can only produce graphs that show usage while JConsole was
running. Administrators cannot look back in time to a point where the JVM was running but JConsole was not
monitoring the JVM.
177
ZenPacks
Figure 23.1. JMX Heap Graph
The MBean tab along the top of JConsole provides an interactive method for examining MBean values. After
clicking on the MBean tab a panel will be displayed with a tree on the left hand side. The tree contains a hierarch-
ical list of all MBeans deployed in the JVM.
The standard JVM MBeans are all in the java.lang and java.util.logging packages. Application server specific
MBeans do not follow any standard naming pattern. Some vendors choose to use package names for their MBean
names while other vendors choose package-like names (but not fully qualified packages).
To get started expand the java.lang node in the Tree. This will expose several MBeans as well as additional folders.
Click on the Memory MBean and observe how the right hand side of the panel is populated with information about
the Memory MBean.
178
ZenPacks
Figure 23.2. Memory MBean
MBeans can contain attributes and operations. MBeans can also fire notifications to observers, but that's beyond
the scope of this document. The attributes tab lists all of the attributes in the first column and their values (or a
clickable attribute type) in the second column. In the case of Memory the HeapMemoryUsage is a Composite at-
tribute, otherwise referred to as a "multi-value attribute" in Zenoss. Double click the "javax.management.openm-
bean.CompositeDataSupport" type and you will see multiple attributes appear. The show the amount of committed,
maxiumum, and used memory sizes for the heap.
179
ZenPacks
Figure 23.3. Memory MBean Expanded
The unique name of the MBean can be viewed by clicking on the Info tab. The first value is MBean Name and it's
value in the case of Memory is: "java.lang:type=Memory". Note that there isn't a standardized way to name MBeans
and application server vendors do it differently.
You can also examine operation information by clicking on the Operations tab. These are methods that JConsole
can remotely invoke on an MBean that will result in some value being computed or some state changing in the
application. The Threading MBean has several operations that can be invoked that return information. Click on
the java.lang package and then click on the Threading operation. Lastly, click on the Operations tab. Methods like
"getThreadUserTime" are invocable.
180
ZenPacks
Figure 23.4. Operations Tab
Test the "getThreadUserTime" method by changing the p0 parameter to 1 and clicking the "getThreadUserTime"
button. A dialog window will be raised that displays the amount of CPU user time thread #1 has used. Try adjusting
the parameter to different values to observe the different CPU times for the threads.
2.12. Installing ZenJMX

Step #1: Install the ZenJMX ZenPack
ZenJMX is installed using the "zenpack" command. As the zenoss user 6 run the following command:
${ZENHOME}/bin/zenpack --install /path/to/ZenJMX-1.0.0-el5-i386.zip
Step #2: Install Sun's JRE
You will need Java SE Version 5.0 or higher. 1.4.2 will NOT work. We have not tested with gcc-java. Make sure
that after you install Sun's JRE you update your PATH such that the "java" executable works. You can test this
using the command "which java" - if it returns a fully qualified path to java you have successfully installed Java.
2.12.1. Installing ZenJMX on an appliance

ZenJMX and Sun's JRE is installed using a conary command. As root run the following command:
conary update --resolve group-zenjmx
181
Appendix A. Net-SNMP and Zenoss
1. Net-SNMP Configuration Settings
These are the Net-SNMP configurations settings that are needed for Zenoss. Add these lines to your snmpd.conf.
1.1. Community Information

This line will map the community name "public" into a "security name":
# sec.name source community
com2sec notConfigUser default public
This line will map the security name into a group name:
# groupName securityModel securityName
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
This line will create a view for you to let the group have rights to:
# Make at least snmpwalk -v 1 localhost -c public system fast again.
# name incl/excl subtree mask(optional)
view systemview included .1
This line will grant the group read-only access to the systemview view.
# group context sec.model sec.level prefix read write
notif
access notConfigGroup "" any noauth exact systemview
none none
1.2. System Contact Information

It is also possible to set the sysContact and sysLocation system variables through the snmpd.conf file:
syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
# Added for support of bcm5820 cards. pass .1 /usr/bin/ucd5820stat
1.3. Extra Information

See the snmpd.conf manual page, and the output of "snmpd -H".
trapcommunity public
trapsink default
182
Appendix B. Event Database Dictionary
1. Event Database Dictionary
Event Database Field Description
dedupid events will deduplicate based on the value of this field.
by default: device, component, eventClass, eventKey,
severity
device name of device
component name of component (like eth0, httpd, etc)
eclass eventClass (if not specified maybe added by rule process
if this fails will be /Unknown)
eventKey If a component needs further deduplication specification
this field maybe used
summary message text truncated at 150 characters
message full message text
severity number from 0 to 5
eventState state of event 0 = new, 1 = acknowledged, 2 = suppressed
eventClassKey key by which rules processing begins. Often equal to
component.
eventGroup logical group of event source (syslog, ping, nteventlog
etc)
stateChange last time event changed automatically updated
firstTime unix timestamp when event is received.
lastTime last time an event was received
count number of times an event has repeated
prodState prodState of the device context
suppid id of event that suppressed this event
manager fqdn of the collector from which this event came
agent collector name from which event came (zensyslog, zen-
trap, etc)
DeviceClass device class from device context
Location device location from device context
Systems device systems from device context separated by |
DeviceGroups device systems from device context separated by |
ipAddress IP from which event came
facility syslog facility of this is syslog event
priority syslog priority of this is syslog event
ntevid nt event id if this is nt eventlog event.
183
Appendix C. TALES Expressions
1. About TALES Expressions
TALES is syntax you can use to retrieve values call methods on Zenoss objects. Several fields in Zenoss accept
TALES syntax, including command templates, event mapping transforms, user commands, event commands,
zProperties, zLinks and others.
Commands (those associated with devices as well as those associated with events) can use TALES expressions to
incorporate data from the related devices and/or events. TALES is a syntax for specifying expressions that let you
access the attributes of certain objects such as a device or an event in Zenoss. For additional documentation on
TALES syntax please see the TALES section at:
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx
Depending on the context you may have access to a device and/or an event. Below is a list of the attributes and
methods you may wish to use on device and event objects. The syntax for accessing device attributes and methods
is ${dev/attributename}, so for example to get the manageIp of a device you would use ${dev/manageIp}. For
events, the syntax is ${evt/attributename}
A command to ping a device might look like this. The ${..} is a TALES expression to get the manageIp value for
the device.
{{{
ping -c 10 ${dev/manageIp}
}}}
More Examples:
DNS forward lookup
(assumes device/id is a resolvable name)

{{{
host ${device/id}
}}}
DNS reverse lookup

{{{
host ${device/manageIp}
}}}
SNMP Walk
{{{
snmpwalk -v1 -c${device/zSnmpCommunity} ${here/manageIp} system
}}}
To use these expressions effectively you need to know which objects, attributes and methods are available to you
in which contexts. Usually there is a dev and/or device which allows you access the device in a particular context.
Contexts related to a particular event usually have evt and/or event defined. Some available attributes for each of
these classes are listed below. List items with parenthesis after them are methods and much have the parenthesis
included in the TALES expression to function correctly.
2. TALES Device Attributes

Attribute Description
getId The primary means of identifying a device within Zenoss
184
TALES Expressions
getManageIp The IP address used to contact the device in most situ-
ations
productionState The production status of the device: Production, Pre
Production, Test, Maintenance or Decommisioned. This
attribute is a numeric value, use getProductionStateString
for a textual representation.
getProductionStateString Returns a textual representation of the productionState
snmpAgent The agent returned from snmp collection
snmpDescr The description returned by the snmp agent
snmpOid The oid returned by the snmp agent
snmpContact The contact returned by the snmp agent
snmpSysName The system name returned by the snmp agent
snmpLocation The location returned by the snmp agent
snmpLastCollection When snmp collection was last performed on the device.
This is a DateTime object.
getSnmpLastCollectionString Textual representation of snmpLastCollection
rackSlot The slot name/number in the rack where this physical
device is installed
comments User entered comments regarding the device
priority A numeric value: 0 (Trivial), 1 (Lowest), 2 (Low), 3
(Normal), 4 (High), 5 (Highest)
getPriorityString A textual representation of the priority
getHWManufacturerName Name of the manufacturer of this hardware
getHWProductName Name of this physical product
getHWProductKey Used to associate this device with a hardware product
class
getOSManufacturerName Name of the manufacturer of this device's operating
system.
getOSProductName Name of the operating system running on this device.
getOSProductKey Used to associate the operating system with a software
product class
getHWSerialNumber Serial number for this physical device
getLocationName Name of the Location assigned to this device
getLocationLink Link to the Zenoss page for the assigned Location
getSystemNames A list of names of the Systems this device is associated
with
getDeviceGroupNames A list of names of the Groups this device is associated
with
getOsVersion Version of the operating system running on this device
getLastChangeString When the last change was made to this device
getLastPollSnmpUpTime Uptime returned from snmp
uptimeStr Textual representation of the snmp uptime for this device
getPingStatusString Textual representation of the ping status of the device
getSnmpStatusString Textual representation of the SNMP status of the device
185
TALES Expressions
3. TALES Event Attributes

dedupid A key used to correlate duplicate events
evid A unique id for the event
device The id of the associated device, if applicable
ipAddress The IP Address of the associated device, if applicable
component The component of the associated device, if applicable
eventClass The event class associated with this device
eventGroup logical group of event source (syslog, ping, nteventlog
etc)
eventKey The eventKey is the primary criteria for mapping events
into event classes
facility syslog facility of this is syslog event
severity One of 0 (Clear), 1 (Debug), 2 (Info), 3 (Warning), 4
(Error) or 5 (Critical)
priority syslog priority of this is syslog event
summary Text description of the event
stateChange When the mysql record for this event was last modified
firstTime The first time this event was seen
lastTime The last time this event was seen and it's count incremen-
ted
count Number of times this event has been seen
prodState prodState of the device context
manager fqdn of the collector from which this event came
agent collector name from which event came (zensyslog, zen-
trap, etc)
zProperties are also available for devices and events using the same syntax as above.
186
Appendix D. Device Preparation
1. Net-SNMP
By default Net-SNMP does not publish the full SNMP tree. Check to see if that is currently the case on a device
and configure it correctly.
1. Confirm snmpd is running:

> snmpwalk -v1 -cpublic <your device name> system
2. Retrieve the IP table for the device with snmpwalk:
> snmpwalk -v1 -cpublic <your device name> ip
Typical SNMP View:

view systemview included .1
view systemview included .1.3.6.1.2.1.25.1
access notConfigGroup "" any noauth exact systemview none none
2. Forwarding Syslog messages from UNIX/Linux Devices

Zenoss has its own syslog server, zensyslog. Managed devices should point their syslog daemons to zenoss. To
do this, edit the /etc/syslog.conf file and add an entry where 1.2.3.4 is the zensyslog IP.
1. Log on to the target device (as a super user).
2. Open /etc/syslog.conf file with a text editor (e.g VI).
3. Enter *.debug and press the Tab key. then enter the host name or IP address of the Zenoss server. See example
below:
*.debug @192.168.X.X
4. Save the file and exit the file editor program.
5. Restart the Syslog service using the command below:

/etc.init.d/syslog restart
3. Forwarding Syslog Messages from a Cisco IOS Router

Here are some links to Cisco commands to turn on syslog. Typically, it’s easier to use syslog than SNMP traps
from network devices. The most basic IOS command to send syslog messages is:
logging 1.2.3.4
3.1. Other Cisco syslog Configurations

Here are some additional configurations for other Cisco devices. To set up these configurations follow the following
steps using the configurations that follow below.
1. Log on to the target router.
187
Device Preparation
2. Type the command enable at the prompt.
3. Once you are prompted for a password, enter the correct password.
4. Type the command config at the prompt.
5. Type the command terminal at the configuration prompt.
6. At the prompt, Set the Syslog forwarding mechanism. See example below:
logging <IP address of the Zenoss server>
7. Exit out all the prompts to the main router prompt.
Catalyst
set logging server enable
set logging server 192.168.1.100
set logging level all 5
set logging server severity 6
Local Director
syslog output 20.5
no syslog console
syslog host 192.168.1.100
PIX Firewalls
logging on
logging standby
logging timestamp
logging trap notifications
logging facility 19
logging host inside 192.168.1.100
4. Forwarding Syslog Messages from a Cisco CatOS

Switch
1. Log on to the target switch.
2. Type the command enable at the prompt.
3. Once you are prompted for a password, enter the correct password.
4. Set the Syslog forwarding mechanism. See example below:

set logging server <IP address of the Zenoss server>
5. You can set the types of logging information that you want the switch to provide with the commands below as
examples:
set logging level mgmt 7 default
set logging level sys 7 default
set logging level filesys 7 default
5. Forwarding Syslog Messages using Syslog-ng

Here is an example for FreeBSD and Linux platforms.
1. Log on to the target device (as a super user)
188
Device Preparation
2. Open /etc/syslog-ng/syslog-ng.conf file with a text editor (e.g VI).
3. Add source information to file. See example below:
FreeBSD:
source src { unix-dgram("/var/run/log"); internal ();};
Linux: (will gather both system and kernel logs)

source src {
internal();
unix-stream("/dev/log" keep-alive(yes) max-connections(100));
pipe("/proc/kmsg");
udp();
};
4. Add destination information (in this case, the Zenoss server). See example below:
log { source(src); destination(zenoss); };
189
Appendix E. Zenoss Licensing
Information
1. ZENOSS CORE (TM) END USER LICENSE AGREE-
MENT
Version 1.0.
The accompanying executable code version of the Zenoss Core™ monitoring platform is made available to you
pursuant to version 2 of the GNU General Public License (the “GPL”). Without limiting your rights under the
GPL, the Zenoss Core™ monitoring platform and related documentation (collectively, the “Product”) are subject
to the terms and conditions of this Zenoss Core™ End User License Agreement (the “Agreement”) and our Privacy
Policy.
BY CLICKING THE "ACCEPT" BUTTON, OR BY INSTALLING OR USING THE ZENOSS CORE™

MONITORING PLATFORM, YOU CONSENT TO BE BOUND BY THE AGREEMENT. IF YOU DO NOT
AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT CHECK THE “ACCEPT"
BOX, AND DO NOT INSTALL OR USE ANY PART OF THE ZENOSS CORE MONITORING PLATFORM.
During the Product installation process, and at later times, you may be given the option of installing additional
components from third-party software providers. The installation and use of those third-party components may be
governed by additional license agreements.
1. Scope of Agreement; GPL License. This Agreement governs the Product and any software upgrades provided
by Zenoss, Inc. (“Zenoss”) that replace and/or supplement the original Product, unless those upgrades are accom-
panied by a separate license, in which case the terms of that license will govern. The accompanying executable
code version of the Zenoss Core™ monitoring platform is made available to you pursuant to the GPL, and nothing
in this Agreement will be construed to limit any rights granted under the GPL.
2. Reservation of Trademark and Other Rights. Subject to the foregoing, Zenoss, for itself and on behalf of its li-
censors, hereby reserves all trademark and all other intellectual property rights in the Product. For example, Zenoss™
and the Zenoss™ logo are trademarks of Zenoss in the United States and other countries, and this Agreement does
not grant any right to use any of those marks or any of the other trademarks, service marks or logos of Zenoss or
its licensors. The GPL is a copyright license which permits you to copy, modify and distribute code which makes
up the Zenoss Core™ monitoring platform, but does not include an implied or express trademark license. You
may not remove or alter any copyright or other proprietary notice in or on the Product.
3. Termination. If you breach this Agreement your right to use the Product will terminate immediately and without
notice, but all provisions of this Agreement except the License Grant (Section 1) will survive termination and
continue in effect. Upon termination, you must destroy all copies of the Product.
4. Disclaimer of Warranty. TO THE FULLEST EXTENT PERMITTED BY LAW, THE PRODUCT IS PROVIDED
ON AN "AS IS" BASIS, WITH ALL FAULTS. YOUR USE OF THE PRODUCT IS AT YOUR OWN RISK.
ZENOSS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION)
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGE-
MENT, SYSTEM INTEGRATION, NON-INTERFERENCE AND ACCURACY OF INFORMATIONAL
CONTENT. ZENOSS DISCLAIMS LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, CONSEQUEN-
TIAL, SPECIAL, EXEMPLARY, PUNITIVE OR OTHER DAMAGES, OR LOST PROFITS, THAT MAY
RESULT, DIRECTLY OR INDIRECTLY, FROM YOUR USE OF THE PRODUCT, INCLUDING (WITHOUT
LIMITATION) ANY DAMAGE TO COMPUTER SYSTEMS, HARDWARE OR SOFTWARE, LOSS OF DATA,
OR ANY OTHER PERFORMANCE FAILURES, OR ANY ERRORS, BUGS, VIRUSES OR OTHER DEFECTS
THAT RESULT FROM OR ARE ASSOCIATED WITH USE OF THE PRODUCT. YOU BEAR THE ENTIRE
RISK AS TO SELECTING THE PRODUCT FOR YOUR PURPOSES AND AS TO THE QUALITY AND
PERFORMANCE OF THE PRODUCT. THIS LIMITATION WILL APPLY NOTWITHSTANDING THE
FAILURE OF ESSENTIAL PURPOSE OF ANY REMEDY. SOME JURISDICTIONS DO NOT ALLOW THE
190
Zenoss Licensing Information
EXCLUSION OR LIMITATION OF IMPLIED WARRANTIES, SO THIS DISCLAIMER MAY NOT APPLY

TO YOU.
5. Limitation of Liability. TO THE FULLEST EXTENT PERMITTED BY LAW, IN NO EVENT WILL ZENOSS,
ITS CONTRACTORS OR ITS LICENSORS BE LIABLE TO YOU OR ANY OTHER PARTY FOR ANY
DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES, REGARDLESS OF THE
BASIS OR NATURE OF THE CLAIM (CONTRACT, TORT OR OTHERWISE), ARISING OUT OF OR IN
ANY WAY RELATING TO THIS AGREEMENT OR THE USE OF OR INABILITY TO USE THE PRODUCT,
INCLUDING (WITHOUT LIMITATION) ANY LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF
DATA, COMPUTER FAILURE OR MALFUNCTION, OR OTHERWISE, EVEN IF ZENOSS, ITS CONTRACT-
ORS OR ITS LICENSORS WERE EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
SOME JURISDICTIONS MAY NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR
CERTAIN INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO SOME OF THE ABOVE LIMITATIONS
MAY NOT APPLY TO YOU.
6. Export Control. This license is subject to all applicable export restrictions. You must comply with all export
and import laws and restrictions and regulations of any United States or foreign agency or authority relating to the
Product and its use. Without limiting the generality of the foregoing, you agree that the Product is not being and
will not be acquired for, shipped, transferred, or re-exported, directly or indirectly, to proscribed or embargoed
countries or their nationals, nor will it be used for nuclear activities, chemical or biological weapons, or missile
projects unless authorized by the U.S. government. Proscribed countries are set forth in U.S. Export Administration
Regulations. You certify that you are not on the U.S. Department of Commerce 's Denied Persons List.
7. U.S. Government End Users. The Product is a "commercial item," as that term is defined in 48 C.F.R. 2.101,
consisting of "commercial computer software" and "commercial computer software documentation," as such terms
are used in 48 C.F.R. 12.212 (Sept. 1995) and 48 C.F.R. 227.7202 (June 1995). Consistent with 48 C.F.R. 12.212,
48 C.F.R. 27.405(b)(2) (June 1998) and 48 C.F.R. 227.7202, all U.S. Government End Users acquire the Product
with only those rights as set forth herein.
8. Miscellaneous.
(a) This Agreement shall be deemed to have been consented to in, and shall be governed by the laws of, the State
of Maryland, U.S.A., excluding its conflict of law provisions. This Agreement shall not be governed by the United
Nations Convention on Contracts for the International Sale of Goods or any adopted version of the Uniform
Computer Information Transactions Act.
(b) In the event that either party initiates an action in connection with this Agreement or any other dispute between
the parties (a “Dispute”), the exclusive jurisdiction of such Dispute shall be in a state court located in Anne Arundel
County, Maryland, U.S.A or a federal court located in Maryland, U.S.A.
(c) Notwithstanding Section 8(b), if you are located in a country that does not have a bilateral or multilateral ruling
enforcement treaty with the U.S.A., the Dispute shall be exclusively and finally resolved by arbitration conducted
in Annapolis, Maryland, U.S.A., in the English language by a sole arbitrator ("Arbitrator") in accordance with the
International Arbitration Rules of the American Arbitration Association ("AAA"). The Arbitrator shall be appointed
by agreement of the parties; if the parties fail to agree upon the Arbitrator within fourteen (14) days of notice of
arbitration provided by either party, the AAA shall appoint the Arbitrator. The Arbitrator, and every person named
on all lists of potential arbitrators, shall be a neutral and impartial lawyer with excellent academic and professional
credentials (i) who has practiced law for at least ten (10) years, with experience in the field of software development
and intellectual property law, and (ii) who has had experience, and is generally available to serve, as an arbitrator.
The Arbitrator shall be bound by the provisions of this Agreement and base the award on applicable law and judicial
precedent. Upon rendering a decision, the Arbitrator shall state in writing the basis for the decision, including the
findings of fact and conclusions of law upon which the decision is based. The Arbitrator shall not grant any remedy
or relief that a court could not grant under applicable law. The Arbitrator's decision shall be final and binding upon
the parties, and shall not be subject to appeal. Judgment on the award or any other final or interim decision rendered
by the Arbitrator may be entered, registered or filed for enforcement in any court having jurisdiction thereof. The
arbitrator shall have the right to issue equitable relief, including (without limitation) preliminary injunctive relief.
191
(d) Notwithstanding anything to the contrary in this Section 8, e ither party may enforce any judgment rendered
in accordance with Section 8(b) or (c) in any court of competent jurisdiction, and Zenoss may seek injunctive or
other equitable relief in any jurisdiction in order to protect its intellectual property rights.
(e) If any part of this Agreement is held invalid or unenforceable, that part shall be deemed to be restated so as to
be enforceable to the maximum extent permissible under law, and the remaining portions will remain in full force
and effect.
(f) A waiver by either party of any term or condition of this Agreement or any breach thereof, in any one instance,
will not waive such term or condition or any subsequent breach thereof.
(g) Except as required by law, the controlling language of this Agreement is English, and any Dispute brought
under this Agreement shall be conducted in the English language. In addition, if you are located in Quebec, Canada,
the following clause applies: The parties hereby confirm that they have requested that this Agreement be drafted
in English. Les parties contractantes confirment qu’elles ont exige quele present contrat et tous les documents as-
socies soient rediges en anglais.
(h) You may assign your rights under this Agreement to any party that consents to, and agrees to be bound by, its
terms; Zenoss Inc. may assign its rights under this Agreement without condition.
(i) Zenoss and you enter into this Agreement as, and shall remain, independent contractors with respect to one
another. Nothing in this Agreement shall create a partnership, joint venture, agency, or employment relationship
between the parties. This Agreement will be binding upon and will inure to the benefit of the parties, their successors
and permitted assigns.
(j) This Agreement constitutes the entire agreement between Zenoss and you concerning the subject matter hereof;
it may be modified only by a written amendment signed by an authorized executive of Zenoss. To the extent of
any conflict or inconsistency between this Agreement and any invoice, purchase order or other document submitted
by you to Zenoss, this Agreement will control. Zenoss’ acceptance of any document shall not be construed as an
acceptance of any provision which is in any way in conflict or inconsistent with, or in addition to, this Agreement,
unless such provision is separately and specifically accepted in writing by an authorized officer of Zenoss.
9.Print a Copy of this Agreement. Zenoss advises you to print a copy of this Agreement on the date that you consent
to the Agreement.
2. GNU General Public License

This documentation is offered under the GNU General Public license (GPL) as defined below.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA
02110-1301 US
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the
GNU General Public License is intended to guarantee your freedom to share and change free software--to make
sure the software is free for all its users. This General Public License applies to most of the Free Software Found-
ation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation
software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
192
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed
to make sure that you have the freedom to distribute copies of free software (and charge for this service if you
wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of
it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to
surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the
software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients
all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must
show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you
legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no
warranty for this free software. If the software is modified by someone else and passed on, we want its recipients
to know that what they have is not the original, so that any problems introduced by others will not reflect on the
original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistrib-
utors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent
this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying
it may be distributed under the terms of this General Public License. The "Program", below, refers to any such
program or work, and a "work based on the Program" means either the Program or any derivative work under
copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications
and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modi-
fication".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its
scope. The act of running the Program is not restricted, and the output from the Program is covered only if its
contents constitute a work based on the Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium,
provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and dis-
claimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and
give any other recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty pro-
tection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the
Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that
you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of
any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
193
c) If the modified program normally reads commands interactively when run, you must cause it, when started
running for such interactive use in the most ordinary way, to print or display an announcement including an appro-
priate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that
users may redistribute the program under these conditions, and telling the user how to view a copy of this License.
(Exception: if the Program itself is interactive but does not normally print such an announcement, your work based
on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived
from the Program, and can be reasonably considered independent and separate works in themselves, then this License,
and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute
the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be
on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather,
the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based
on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope
of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable
form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under
the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more
than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding
source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software
interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This
alternative is allowed only for noncommercial distribution and only if you received the program in object code or
executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable
work, complete source code means all the source code for all modules it contains, plus any associated interface
definition files, plus the scripts used to control compilation and installation of the executable. However, as a special
exception, the source code distributed need not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of the operating system on which the execut-
able runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering
equivalent access to copy the source code from the same place counts as distribution of the source code, even
though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.
Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically ter-
minate your rights under this License. However, parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you
permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you
do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program),
you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or
modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives
a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.
194
You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not
responsible for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited
to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict
the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute
so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-
free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only
way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the
section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest
validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distri-
bution system, which is implemented by public license practices. Many people have made generous contributions
to the wide range of software distributed through that system in reliance on consistent application of that system;
it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a
licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted
interfaces, the original copyright holder who places the Program under this License may add an explicit geograph-
ical distribution limitation excluding those countries, so that distribution is permitted only in or among countries
not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from
time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address
new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License
which applies to it and "any later version", you have the option of following the terms and conditions either of that
version or of any later version published by the Free Software Foundation. If the Program does not specify a version
number of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are
different, write to the author to ask for permission. For software which is copyrighted by the Free Software
Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be
guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the
sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE
PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE
STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM
"AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PAR-
TICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NE-
CESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY
COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE
PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY
TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
195
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF

THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER
PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
196

Zenoss Administration Guide Zenoss

Uploaded by

Copyright:

Available Formats

Zenoss Administration Guide Zenoss

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zenoss Administration Guide Zenoss

Uploaded by

Copyright:

Available Formats

Zenoss Administration Guide

Zenoss Administration Guide

3.7. Creating Object Associations .................................................................................... 21

8.9. Custom Tab ........................................................................................................... 58

14.2. Test the Event Command ........................................................................................ 86

4. ZenWin Command Line Parameters .................................................................................... 119

3. Checking the Version of Zenoss .......................................................................................... 157

2.6.5. Scenario #5: Multiple parameters in polymorphic operations .............................. 173

Figure 1.1. Zenoss High-Level Architecture

1.1. The Zenoss Standard Model

1.2. Availability Monitoring in Zenoss

1.3. Zenoss Event Management System

1.4. Zenoss Performance Monitoring System

Figure 2.1. Zenioss Detailed Architecture

Dashboard Events Locations

4. Collection and Control Services Layer

4.1. Automated Modeling Daemons

4.2. Availability Modeling Daemons

4.3. Event Collection Daemons

4.4. Performance Monitoring Daemons

4.5. Automated Response Daemons

3. Inheritance and Path Navigation

Figure 4.1. Zenoss Dashboard

2. Left Navigation Menu

Hiding the Left Navigation Menu

2.1. Main Views

Mibs - Add New organizer, Add new MIBS

Monitors - Status Monitors and Performance Monitors

Settings - Settings, commands users ZenPacks Menus Daemons Versions

2.4. Hiding the Left Navigation Menu

4. Device/IP Search Box

5. User Information Area

6. Customizing Zenoss Dashboard Portlets

Figure 4.2. Column Layout Dialog

Figure 4.3. Add Portlet Dialog

• Top level Organizers

6.1. Devices Issues Portlet

Figure 4.4. Device Issues Portlet

6.1.1. Configuring the Device Issues Portlet

Figure 4.5. Device Issues Portlet Configuration

6.2. Top Level Organizers

Figure 4.6. Top Level Organizer Portlet

6.2.1. Configuring the Top Level Organizer Portlet

Figure 4.7. Top Level Organizer Configuration

6.3. Watch List Portlet

Figure 4.8. Watch List Portlet

6.3.1. Configuring the Watch List Portal

Figure 4.9. Watch List Portlet Configuration

6.4. Google Maps Portlet

Figure 4.10. Google Maps Portlet

6.4.1. Configuring the Google Maps Portlet

Figure 4.11. Configuring the Google Maps Portlet

6.5. Zenoss Issues Portlet

Figure 4.12. Zenoss Issues Portlet

6.5.1. Configuring the Zenoss Issues Portlet

Figure 4.13. Configuring the Zenoss Issue Portlet

6.6. Production States Portlet

Figure 4.14. Production State Portlet

6.6.1. Configuring the Production States Portlet

Figure 4.15. Configuring the Production State Portlet