---

Subject:	This should work perfectly
Author:	Jane Curry
Posted:	2017-04-11 05:56

This should work perfectly well with the free Zenoss Core provided your SNMP community names are configured in the target device and in Zenoss.

If you inspect your Cisco device in Zenoss, does it have Interface Components in the left-hand menu?  If yes, then some SNMP communications have been sccessful to the device; if not, then the issue is probably community names.

Zenoss has a default SNMP configuration to use a community name of public to all devices.  This can be changed for a device class (like Devices -> Network -> Router -> Cisco), in which case, all devices in that class will inherit the value.  If you want a different community name for a specific device then you can have a device-level override. 

From the main page for the test device in Zenoss, select Configuration Properties. zSnmpCommunity and zSnmpVer are the key things you need to match with what is configured in your router.

I would use the snmpwalk utility from a command-line window to do some testing so, for device fred, using snmp v2c with a community name of mycomm, try:

snmpwalk -v 2c -c mycomm fred

Cheers,

Jane

 

Email: jane.curry@skills-1st.co.uk    Web: https://www.skills-1st.co.uk

---

Subject:	zenperfsnmp.log
Author:	[Not Specified]
Posted:	2017-04-18 10:07

In the zenperfsnmp.log, I am seeing quite a bit of the following:

WARNING zen.zenperfsnmp: Error reading value

ERROR zen.zenperfsnmp: SNMP get returned empty value

According to this article, I might need to add a ".0 in the OIDs for each datasource in the template for that device."   Though I'm not sure how exactly to do that.

http://zenoss-users.zenoss.narkive.com/YChdEGZ1/empty-graphs-upon-new-install-of-zenoss-3-2#post2

Is this why I am seeing the localhost zenperfsnmp heartbeat failures consistently?

Am I barking up the wrong tree?  Why did it work for a few short hours?

---

Subject:	More info
Author:	[Not Specified]
Posted:	2017-04-18 11:50

One thing to add is when I issue the command manually:

zenperfsnmp run -v10 -d devicename

One of the final DEBUG messages are:

zen.pbclientfactory: Lost connection to 127.0.0.1:8789 - [Failure instance: Traceback (failure with no frames): : Connection to the other side was lost in a non-clean fashion: Connection lost.

]

Any idea what this is?

---

Subject:	Hi Tepz,
Author:	Jane Curry
Posted:	2017-04-19 10:59

Hi Tepz,

A number of things here....

If you did manage to see graph data for 4 hours, that suggests that you don't have a fundamental SNMP communications problem - unless you have an auto configuration tool (puppet? chec?) that runs around and reconfigures lots of things at 8 pm?  Or a firewall rule changes then?

In the main page for each device, it should show when it was last modeled - is this updated regularly?  Every 12 hours be default?

zenperfsnmp is the man getting the performance data for you and lots of zenperfsnmp heartbeat events is bad news.  zenperfsnmp gathers the data and writes to the RRD files.  Is your Zenoss server machine short on memory? CPU? disk?  Are any other Zenoss daemons showing heartbeat issues?

 

The:

WARNING zen.zenperfsnmp: Error reading value

ERROR zen.zenperfsnmp: SNMP get returned empty value

messages are suggesting that your target devices are not responding, especially the ERROR message.  This points more to taget issues than Zenoss issues.

For interface traffic, do not add .0 to the OID.  interfaces are components of a device ie. potentially lots of them.  SNMP gets data for each different interface based on the last part of the OID - the modeler process works out what that index is and automatically uses it when running the template for interface information.  Where the ".0" bit can come in is with templates that use SNMP to get SCALAR data from a device - for example, there is only one answer to "what is your total RAM" - it is represented in SNMP as a scalar type and a template using that OID would then need the ".0" on the end.  Not relevant for interfaces / filesystems or any other component templates.

Ignore the nasty message about "Connection to the other side was lost in a non-clean fashion" - various Zenoss daemons have done this forever and it is actually nothing to worry about.

Cheers,

Jane

 

Email: jane.curry@skills-1st.co.uk    Web: https://www.skills-1st.co.uk