Wouldn't it be nice if everything just worked? Unfortunately, we can expect to make a mistake or two.
If you see an event in Zenoss that reports SNMP agent down, we first need to find out whether the issue is with Zenoss Core or with the device.
Note
Not all network devices support SNMP. So, before you beat yourself up troubleshooting, make sure your device supports SNMP.
Zenoss Core includes a command that will run the snmpwalk command on the selected device. The snmpwalk command will query the device using the SNMP community string we assigned to the device and will try to get a list of the OIDs. Let's try it.
Navigate to Infrastructure and select Devices. Select a device (by clicking on the device name) that should respond to SNMP requests. The device's Overview page displays.
- At the bottom of the sidebar, expand the Commands menu and select snmpwalk.
- The command runs against the device and returns the result, as shown in the following screenshot:
The previous screenshot indicates that Zenoss Core was able to retrieve data from the device successfully. If you have problems, the snmpwalk command will either timeout or be refused.
If you're having problems connecting, check the SNMP Community attribute (zSnmpCommunity) from the Configuration Settings of the device to make sure it's correct.
If problems continue, let's move to the device itself and run the snmpwalk command, assuming we're working with a Linux server. The snmpwalk command is included in the SNMP utilities we installed in Chapter 2,
Run this command on the problem device:
snmpwalk -c public -v 2c localhost
If the command is successful, pages of results will scroll by the terminal. You should check to make sure the device is allowing incoming connections on port 161/UDP and that both the device and Zenoss Core are using the correct community strings.
You should also check to make sure the snmpd daemon is running. Run the following command to check:
ps aux | grep snmpd
We expect to see /usr/bin/snmpd running in the process list. If you don't see snmpd, then install it as per the Prepare devices for monitoring section in Chapter 2,
If you are still having problems, review the SNMP zProperties for the device. You can try different SNMP versions and make sure SNMP monitoring is enabled. To find the zProperties for a device, navigate to the device's status page. Then click on the Configuration Properties link.
A description of the zProperties of all devices is included at the end of this chapter.
Assuming the snmpwalk fails when run from Zenoss Core, make sure SNMP is installed on the server (see Chapter 2,
The built-in Windows SNMP client doesn't provide as much information as Net-SNMP does for our Unix-based systems. You may be wondering why Zenoss Core isn't collecting file system information or CPU statistics. You need a third-party SNMP agent for Windows. Try the free SNMP agent from http//:www.snmp-informant.com.
The first thing you should do is to make sure you have WMI installed as per the instructions in Chapter 2, Discovering Devices, and have verified the setup.
If you see an event that indicates zeneventlog is unable to connect to Windows, that's an indication Zenoss Core is not able to authenticate to the Windows server. Check the Configuration Properties (zProperties) of the device to ensure you have the correct username and password set.
The following screenshot shows the WMI specific zProperties:
Remember, the zWinUser and zWinPassword properties must be an administrator on the Windows server you're monitoring. It's possible that each of your Windows servers could require a different username and password.
The zWinUser property can be either a local or a domain account. If you use a domain account, specify the domain for the zWinuser value (for example, mojoactiveadministrator).
It's possible that Zenoss Core isn't collecting any data from the Windows Servers via WMI, but there are no events reported. You can check the following zProperties at the device or class level:
- Make sure the device is using the
zenoss.wmi.WinServiceMapcollector plugin - Set the zWmiMonitorIgnore property to False in the Configuration Properties for the device or device class
- If you want to collect event logs, set the zWinEventlog property to True in the Configuration Properties for the device or device class
In Chapter 2, Discovering Devices we installed the Zenoss plugins on Unix hosts that we may not be able to monitor with SNMP, such as remote Linux or OSX servers. If you're encountering problems, there are several zProperties that affect how successfully you can monitor remote machines. See the following screenshot:
There are several points of failure, but the most probable error is that the zCommandPath value is not valid if you installed the Zenoss Plugins as I described. The zenplugin.py file is installed to /usr/bin. And as you can see, the zCommandPath is pointing to /usr/local/zenoss/libexec. This means that each time Zenoss Core tries to collect data from the device using the remote command, it's trying to run /usr/local/zenoss/libexec/zenplugin.py on the remote server.
Change the zCommandPath property to reflect the actual path to zenplugin.py on the remote server, such as /usr/bin.
In order for Zenoss Core to connect to the remote server, it must supply valid user credentials. Check the zCommandUsername and the zCommandPassword properties to ensure they contain a valid username and password for the remote server.
Zenoss Core provides the /Server/Cmd class specifically for monitoring remote machines. The collector plugins are specifically designed to interact with zenplugin.py and retrieve data about the remote server. The following screenshot shows the collector plugins assigned to the /Server/Cmd class.
You won't find any SNMP collectors here.