Device Management in Zenoss Core Network and System Monitoring: Part 2

Exclusive offer: get 50% off this eBook here
Zenoss Core Network and System Monitoring

Zenoss Core Network and System Monitoring — Save 50%

A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system - with a Foreword by Mark R. Hinkle, VP of Community Zenoss Inc.

$23.99    $12.00
by | November 2009 | Networking & Telephony Open Source

Read Device Management in Zenoss Core Network and System Monitoring: Part 1 here.

Model Devices

When we talk about Zenoss, two related but different words often come up, monitoring and modeling. Monitoring refers to the availability of the device and answers the question, "Is the device accessible?" Modeling defines a relationship between devices and identifies the components available on a device, such as services, interfaces, and file systems.

Zenoss models devices via SNMP, SSH, port scan, and telnet and gathers information via collector plug-ins. Each class has a default set of collector plug-ins that tells Zenoss how to model the devices assigned to the class. We can add or remove collector plug-ins at the device level for individual changes or at the class level for all the devices in the class.

The collector plug-in names reflect the monitoring protocol they are used for. All the SNMP collectors contain "snmp" in the name. The SSH and telnet plug-in names contain "cmd," and the port scan plug-in contains "portscan" in the name.

We'll step through modeling examples for SNMP, SSH, and port scan; however, we'll skip telnet because it's similar to SSH.

SNMP

Zenoss defaults to SNMP monitoring, and the monitored device needs to have SNMP installed and configured to work properly.

Zenoss supports SNMP v1, v2c, and v3. The example commands used in this section to troubleshoot SNMP specify v1.

Test SNMP

If we're unsure of our SNMP setup, we can test it by running the snmpwalk command to retrieve the values of the MIB tree on the monitored device. We'll demonstrate both working and broken SNMP configurations on the MillRace network.

From the Device List, select the device named Coyote. From the Device Status page menu, choose Run Commands > snmpwalk. A new window opens and we see the results of the snmpwalk command as shown in the following screenshot.

device management in zenoss core network and system monitoring

Now we select the device Bobcat from the Device List view. Run the snmpwalk command from the Device Status page. This time, we receive a Timeout error, which indicates that we have a problem with SNMP on the device Bobcat as shown in the following screenshot.

device management in zenoss core network and system monitoring

Assuming that SNMP is properly configured on the device and that the monitored device accepts traffic on port 161, we may need to update the device's community string. To update the community:

  1. Select the device from the Device List view.
  2. From the Device Status page menu, select More > zProperties.
  3. Find the Community field and enter the correct value.
  4. Save the changes.

After updating the SNMP community string in the zProperties, we run the snmpwalk command again to see if we have fixed the problem.

If we continue to encounter problems getting Zenoss to model a device with SNMP, we can try to narrow down the problem by running the following snmpwalk command from the monitored devices shell prompt:

snmpwalk -v1 -c public localhost system

Replace public with the correct community string. If the command is successful when using localhost, edit the snmpd configuration file. As root, edit /etc/default/snmpd or /etc/default/snmp and remove 127.0.0.1 from the following line:

SNMPDPORTS = '-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

After editing the /etc/default/snmpd file, restart the snmpd service as root. For example:

/etc/init.d/snmpd stop
/etc/init.d/snmpd start

Retest the snmpwalk command to confirm that SNMP is working correctly.Windows users can run wbemtest from the command line to test SNMP.

Windows Considerations

In order to collect information from WMI,regarding the Windows SNMP installation we need to configure the zProperties for the Windows device. Navigate to the Windows device and open the zProperties page by selecting the More > zProperties from the page menu. Scroll to the bottom of the page and make the following changes:

  • Set zWinEventLog to true.
  • Enter the Windows user's password in the zWinPassword field.
  • Enter the user name with administrative rights in the zWinUser field in the following formats:
    • .user for local user accounts
    • DOMAINuser for domain user accounts
  • Set zWMIMonitorIgnore to false.

Save the changes, and Zenoss is ready to model the information on the Windows device. We can force a model by selecting Manage > Model Device from thepage menu.

SNMP Collector Plug-ins

The Collector Plug-ins assigned to the device determines how Zenoss models the device. Let's take a look at our example device Coyote and see what collectors are currently assigned. From the Device Status page for Coyote, select More > Collector Plug-ins from the page menu.

A page showing the assigned collector plugi-ns displays in the left column of the page with an Add Fields link on the right. When we click on the Add Fields link, a column of unassigned plug-ins appears and the link name changes to Hide Fields as shown in the following screenshot.

Device Management in Zenoss Core Network and System Monitoring

The plug-in names are intuitive in that the name suggests the type of information we expect to be modeling. For example, zenoss.snmp.IpServiceMap returns a list of active IP services on the device, such as HTTP. The Dell specif?i c plugi-ns retrieve more detailed information from Dell devices using OpenManage, and the HPplugi-ns provide more information about devices using Insight Management agents.

To remove a plug-in from the assigned plug-in list, click on the "x" next to the plug-in name. To assign a plug-in, drag the plug-in name from available list to the assigned list.

To see how our devices are affected, let's remove the zenoss.snmp.IpServiceMap and add zenoss.cmd.df. After we make the changes to the plug-ins for Coyote, scroll to the bottom of the page and click Save.

Model Device

Zenoss automatically models each device in our inventory every six hours, but we can manually force Zenoss to model the device. From the Device Status page, select Manage > Model Device from the page menu.

Zenoss displays the results of the zenmodeler command in the window as shown in the following screenshot.

Device Management in Zenoss Core Network and System Monitoring

Zenoss first determines which plugi-ns are available and then collects information based on those plug-ins. Notice that no cmd plug-ins are found, which means that the zenoss.cmd.df plug-in we added to Coyote will not be collected. After Zenoss models the device, we can review the device overview page to see what component types Zenoss discovered. IpService should not be listed.

If we go back to the Collector Plug-ins page for Coyote, we can add the zenoss.snmp.IpService plug-in and then model the device again. Now, IpServices is displayed in the Component Type list as shown in the following screenshot.

Device Management in Zenoss Core Network and System Monitoring

The Component Type list gets updated as part of the modeling process and so does the OS fields in the Device Information table (the greyed-out fields in the screen shot). If we enter values in these fields during the Add Device step, the values would be overwritten with the SNMP values.

Our example made changes to the device level, which means that if we view the collector plug-ins for the /Server/Linux device class, the original plug-ins are specified. To view the plug-ins for the class:

  1. Select Devices from the navigation panel.
  2. Select Server from the sub-devices list.
  3. Select Linux from the sub-devices list.
  4. From the /Devices/Server/Linux page menu, select More > CollectorPlug-ins.

Devices automatically inherit any changes we make to the class collector plug-ins the next time Zenoss models the devices.

SSH Modeling

If the monitored device does not support SNMP, or if we need to monitor a device behind a firewall, SSH provides an alternative to SNMP. Unlike SNMP, SSH needs the Zenoss Plug-ins installed on each monitored device and platform support is limited to Linux, Darwin, and FreeBSD. We also need to make sure that the monitored device has an SSH server installed so that the Zenoss system can log in and retrieve information. OpenSSH from openssh.com offers a good cross-platform SSH solution.

The level of modeling provided by the Zenoss Plug-ins varies between platforms. For this reason, we may not achieve the same level of detail as we do with SNMP, but SSH modeling provides more detail than a port scan.

To help us setup our SSH monitoring, Zenoss provides the /Server/Cmd class which is already configured with the command plug-ins we need to monitor via SSH.

SSH Collector Plug-ins

From the navigation panel, select Devices. Navigate to the /Server/Cmd class and click on the zProperties tab. Find the zCollectorPlug-ins field and click on the Edit link. A list of the assigned collector plug-ins is displayed as shown in the following screenshot.

Device Management in Zenoss Core Network and System Monitoring

The important thing to note with the command collector plug-ins is the new level of specificity in the name. The zenoss.cmd.uname and zenoss.cmd.df plug-ins are common to all architectures, while the plug-ins with "linux" in the name work with Linux systems. Mac OS X platforms use the plug-ins with "darwin" in the name.

If we did not have any any OS X systems to monitor, then we could remove allthe Darwin-based plug-ins from the /Server/Cmd class or, if we know that wedon't want to monitor the memory usage for any of our devices, we can removethat plug-in.

We'll leave the collector plug-ins as they are for the /Server/Cmd class and change our test device Coyote to use SSH instead of SNMP.

Zenoss Plug-ins

Zenoss will monitor and retrieve some data using the SSH modeler even if we do not install the Zenoss plug-ins, but the device model will be incomplete. For example, file systems will be detected along with the size of each drive., but the usage statistics will not be reported. Zenoss also generates warning events if it cannot find the zenplugin.py command on the monitored system.

The monitored system needs a Python environment installed. This can beinstalled using your distribution's package manager. If you have setuptoolsinstalled, you can install the Zenoss-Plug-ins package from the Cheese Shop (http://pypi.python.org/pypi/) with the following command as root:

easy_install Zenoss-Plugins

We can also build the Zenoss Plug-ins package from source:

  1. Download the Zenoss Plug-ins package from http://www.zenoss.com/download/.
  2. Extract the plug-in file.
  3. From the plug-in source directory, run the following commands as root:
    • python setup.py build
    • python setup.py install

The setuptools procedure installs zenplugin.py to /usr/bin, which is important because we need to configure the device zProperties to look for the plug-ins in the correct location.

To ensure that the plug-in file is working correctly, run the following command on the monitored device, which is Coyote in our example:

zenplugin.py –list-plugins

The command outputs the detected platform and the supported plug-ins as shown in the following screenshot.

Zenoss Core Network and System Monitoring A step-by-step guide to configuring, using, and adapting this free Open Source network monitoring system - with a Foreword by Mark R. Hinkle, VP of Community Zenoss Inc.
Published: June 2008
eBook Price: $23.99
Book Price: $39.99
See more
Select your format and quantity:

Model Device

In order to get Zenoss to model Coyote, we need to tell Zenoss how to connect. First, we'll change the class to /Server/Cmd because it's already configured with theplug-ins we need to use. Second, we'll configure the zProperties so that Zenoss can log in to the device and run system commands.

Navigate to Coyote's Device Status page, and from the page menu, selectManage > Change Class. Select /Server/Cmd and confirm the selection by clicking OK.

Next open the zProperties. From the page menu, select More > zProperties. Make the following changes:

  • Set zCommandUsername to the SSH login on the monitored device.
  • Set the user's password in zCommandPassword.
  • Change zCommandPath to /usr/bin.
  • Set zSnmpMonitorIgnore to true.

When we type the password in zCommandPassword, it will be in clear text, but after we save the zProperties, the password will be starred out. After we have all the changes entered, click Save.

Find the zCollectorPlug-ins field and click on the Edit link to display the collector plug-ins page. Verify the plug-ins listed are for the /Server/Cmd class only. If not, remove the SNMP plug-ins and add the cmd plug-ins. Save any changes.

Now, let's model the device. From the page menu, select Manage > Model Device.

Device Management in Zenoss Core Network and System Monitoring

The modeling process resembles the process for SNMP, but notice that this time we're using the cmd plug-ins instead of the SNMP.

Port Scan Modeling

Sometimes, the only option we have to model our devices is with a port scan. A port scan tries to guess which services are running on a device by connecting to various ports. Port scans provide the least detailed model and may raise security alerts on your network. Consult the security administrators before port scanning devices on the network.

Zenoss creates a separate device class in /Server/Scan to handle these devices. There is only one plug-in available, and it is named zenoss.portscan.IpServiceMap. As the name implies, it returns a list of services running on the device.

We go through the same steps to model a device with port scan as we do for SNMP and SSH.

OS Tab

After Zenoss models the devices, it populates the operating system (OS) tab with its findings. From the device's Status page, click on the OS tab.

Device Management in Zenoss Core Network and System Monitoring

we see that Zenoss has detected the Interfaces, IP Services, File Systems, and Routes for our server, Fox as shown in the previous screenshot. Those groupings should sound familiar,as we've seen various implementations of those collector plug-ins for SNMP andSSH plug-ins.

Hardware Tab

With the exception of the port scan, the Zenoss models include information about a device's memory and CPU. We can access the Hardware tab by clicking the tab labeled Hardware from the Device Status page.

Device Management in Zenoss Core Network and System Monitoring

If we monitor a Windows system, we can gather hard disk information by adding the zenoss.snmp.InformantHardDiskMap collector plug-in to the device.

Device zProperties

In the course of this article, we have changed several zProperties at the device or class level to define how we monitor our devices. The following table lists the available zProperties and a description of each.

zProperty

Description

zCollectorClientTimeout

Set the timeout of the client collector in seconds. The default is 180.

zCollectorDecoding

Specify the character encoding. The default is latin-1.

zCollectorLogChanges

Set to true to log changes and false not to log changes to the collector.

zCollectorPlug-ins

Click the Edit link to open the collector plug-in selection page.

zCommandCommandTimeout

Time in seconds to wait for a command to finish. The default is 15.

zCommandCycleTime

Specifies a time in seconds to cycle through zCommands. The default is 60.

zCommandExistanceTest

Test to see if a command exists on the monitored device. The default is 'test -f %s'.

zCommandLoginTimeout

Wait for the specified seconds for a login prompt. The default is 10.

zCommandLoginTries

Attempt to log in the number of specified times. The default is 1.

zCommandPassword

Enter the password for the user's shell account on the monitored device.

zCommandPath

Enter the path of the zenplugin.py command. The default is /opt/zenoss/libexec; however, the default installation path for zenplugin.py is /usr/bin

zCommandPort

The port the monitored system uses for SSH connections. The default is 22.

zCommandProtocol

Specify the protocol (telnet, ssh) to use. The default is SSH.

zCommandSearchPath

Specify all the paths to search for the commands.

zCommandUsername

Enter the user log in name for the monitored device.

zDeviceTemplates

Enter the templates by name to use to display information. The default is device.

zFileSystemMapIgnoreNames

Enter the names of the files system to ignore. For example: /boot.

zIcon

Each device class has a default icon that can be changed as necessary.

zIfDescription

Displays the interface description on the Interfaces table of the OS tab. Select either true or false. The default is false.

zInterfaceMapIgnoreNames

Enter the names of the interfaces to ignore. For example: lo.

zInterfaceMapIgnoreTypes

Enter the type of interfaces to ignore. For example: local loopback.

zIpServiceMapMaxPort

Specify the maximum port number to port scan. The default is 1024.

zKeyPath

Specify the path to the user's public key file for use with public-key authentication.

zLinks

Enter HTML markup or TALES expressions to display a link for the device. For example, you can create a link to a router's administration console that will display on the Device Status page.

zCommandLoginTries

Attempt to log in the number of specified times. The default is 1.

zCommandPassword

Enter the password for the user's shell account on the monitored device.

zCommandPath

Enter the path of the zenplugin.py command. The default is /opt/zenoss/libexec; however, the default installation path for zenplugin.py is /usr/bin

zCommandPort

The port the monitored system uses for SSH connections. The default is 22.

zCommandProtocol

Specify the protocol (telnet, ssh) to use. The default is SSH.

zCommandSearchPath

Specify all the paths to search for the commands.

zProperty

Description

zCommandUsername

Enter the user log in name for the monitored device.

zDeviceTemplates

Enter the templates by name to use to display information. The default is device.

zFileSystemMapIgnoreNames

Enter the names of the files system to ignore. For example: /boot.

zIcon

Each device class has a default icon that can be changed as necessary.

zIfDescription

Displays the interface description on the Interfaces table of the OS tab. Select either true or false. The default is false.

zInterfaceMapIgnoreNames

Enter the names of the interfaces to ignore. For example: lo.

zInterfaceMapIgnoreTypes

Enter the type of interfaces to ignore. For example: local loopback.

zIpServiceMapMaxPort

Specify the maximum port number to port scan. The default is 1024.

zKeyPath

Specify the path to the user's public key file for use with public-key authentication.

zLinks

Enter HTML markup or TALES expressions to display a link for the device. For example, you can create a link to a router's administration console that will display on the Device Status page.

zSnmpTries

Number of times Zenoss tries to connect via SNMP before reporting a failure.

zSnmpVer

The version of SNMP. Available options are 1, 2c, and 3. Defaults to 1.

zStatusConnectTimeout

Specifies the time in seconds for an IP service to respond before the service is marked down. The default is 15.

zSysedgeDiskMapIngoreNames

Not used.

zTelnetEnable

On Cisco routers, send the enable command to enable command collection. Default is false.

zTelnetEnableRegex

Match the enable prompt with the specified regular expression.

zTelnetLoginRegex

Match the login prompt with the specified regular expression.

zTelnetPasswordRegex

Match the password prompt with the specified regular expression.

zTelnetPromptTimeout

Specify the time in seconds to wait for the login prompt to display.

zTelnetSuccessRegexList

Match the command prompt with the specified regular expression.

zTelnetTermLength

Select true to enable telnet terminal length.

zWinEventLog

Specifies whether or not Zenoss collects the Windows event log. Default is false.

zWinEventLogMinSeverity

Collect all Windows event logs that match the specified severity. Enter a value between 1 and 5, where 1 is the most severe. The default is 2.

zWinPassword

Enter the Windows user's password.

zWinUser

Enter the user name of an account on the monitored Windows system.

zWmiMonitorIgnore

Set to true to ignore WMI monitoring and set to false to monitor WMI services.

zFileSystemMapIgnoreTypes

Do not use

zPythonClass

Do not use

zXmlRpcMonitorIgnore

Set to true to enable XML/RPC monitoring

Summary

As we see, Zenoss aggregates a large amount of information about our networks. In this article, we've learnt how to use classes, plug-ins, and modeling protocols to organize, collect, and display information about our devices. By using the device classes, we can define a hierarchical set of monitoring properties for groups of devices.

The classes allow us to set the collector plug-ins and define a common set of zProperties per device. Exceptions can be made on a per device basis. This is one of Zenoss's core data organization concepts. We can change a device's class or zProperties at any time and Zenoss will apply the changes the next time it models the device.

[ 1 | 2 ]

If you have read this article you may be interested to view :


About the Author :


Books From Packt

trixbox CE 2.6
trixbox CE 2.6

Cacti 0.8 Network Monitoring
Cacti 0.8 Network Monitoring

FreePBX 2.5 Powerful Telephony Solutions
FreePBX 2.5 Powerful Telephony Solutions

Zabbix 1.6 Network Monitoring [RAW]
Zabbix 1.6 Network Monitoring [RAW]

JBoss AS 5 Development
JBoss AS 5 Development

eZ Publish 4: Enterprise Web Sites Step-by-Step
eZ Publish 4: Enterprise Web Sites Step-by-Step

Alfresco 3 Enterprise Content Management Implementation
Alfresco 3 Enterprise Content Management Implementation

ADempiere 3.4 ERP Solutions
ADempiere 3.4 ERP Solutions

No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
S
7
G
Z
j
7
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software