|
|
| Author |
Message |
jlintz
Joined: 21 Nov 2008 Posts: 4
|
Posted: Fri Nov 21, 2008 1:17 pm Post subject: cactid returning wrong value for OID |
|
|
Hi,
I am creating a template to graph from jvm memory stats and running into an odd situation where spine is saying it's using one oid, but returning the value for another oid. Here's an example of the output...
cacti.log output
-----------------
#
11/21/2008 11:10:05 AM - SPINE: Poller[0] Host[197] DS[5211] SNMP: v2: djava01, dsname: jvmSurvivorSpaceUse, oid: 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.3, value: 4923904
#
11/21/2008 11:10:05 AM - SPINE: Poller[0] Host[197] DS[5210] SNMP: v2: djava01, dsname: jvmOldGenUsed, oid: 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.4, value: 4923904
#
11/21/2008 11:10:05 AM - SPINE: Poller[0] Host[197] DS[5209] SNMP: v2: djava01, dsname: jvmEdenSpaceUsed, oid: 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.2, value: 4923904
#
11/21/2008 11:10:05 AM - SPINE: Poller[0] Host[197] DS[5208] SNMP: v2: djava01, dsname: jvmCodeCacheUsed, oid: 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.1, value: 4923904
#
#
#
snmpwalk
---------------------
snmpwalk -v2c -cxxxxx djava01 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11
#
JVM-MANAGEMENT-MIB::jvmMemPoolUsed.1 = Counter64: 4923904 bytes
#
JVM-MANAGEMENT-MIB::jvmMemPoolUsed.2 = Counter64: 142451928 bytes
#
JVM-MANAGEMENT-MIB::jvmMemPoolUsed.3 = Counter64: 53673984 bytes
#
JVM-MANAGEMENT-MIB::jvmMemPoolUsed.4 = Counter64: 147564240 bytes
#
JVM-MANAGEMENT-MIB::jvmMemPoolUsed.5 = Counter64: 70917664 bytes
As you can see its always returning the value for jvmMemPoolUsed.1
Cacti Version 0.8.7b
cacti-spine-0.8.7-1 on centos 5.2
I've tried rebuilding the poller cache and recreating the data template a couple of times but can not understand how spine is getting the same value for each OID. Any help is appreciated.
I should also mention I tried filing a bug report but there seems to be an issue currently with singing up. I get the link to my email and I goto set my password and recieve an error "Invalid form security token. Did you submit the form twice by accident?" |
|
| Back to top |
|
 |
jlintz
Joined: 21 Nov 2008 Posts: 4
|
Posted: Fri Nov 21, 2008 3:36 pm Post subject: |
|
|
More information, it seems that when there is more then one value from the table oid 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11
ie 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.1 , 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.2 , etc...
it will only return one value for all of them and not use each value of the table row |
|
| Back to top |
|
 |
khufure Cacti User
Joined: 24 Oct 2007 Posts: 164 Location: San Francisco, CA
|
Posted: Fri Nov 21, 2008 4:59 pm Post subject: |
|
|
| jlintz wrote: | More information, it seems that when there is more then one value from the table oid 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11
ie 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.1 , 1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.2 , etc...
it will only return one value for all of them and not use each value of the table row |
Try MAXOID per request to 1 in device settings? |
|
| Back to top |
|
 |
jlintz
Joined: 21 Nov 2008 Posts: 4
|
Posted: Fri Nov 21, 2008 5:16 pm Post subject: |
|
|
| Thanks! That did the trick , setting MAXOID to 1. Would you be able to explain why this is occurring? |
|
| Back to top |
|
 |
khufure Cacti User
Joined: 24 Oct 2007 Posts: 164 Location: San Francisco, CA
|
Posted: Fri Nov 21, 2008 5:22 pm Post subject: |
|
|
| jlintz wrote: | | Thanks! That did the trick , setting MAXOID to 1. Would you be able to explain why this is occurring? |
Some buggy snmp devices hate MAXOID above 1. Example, some netapps, routers, apparently jvm memory stats, etc. Unfortunately I've run into this with many devices now and it's consistently annoying to debug  |
|
| Back to top |
|
 |
jlintz
Joined: 21 Nov 2008 Posts: 4
|
Posted: Fri Nov 21, 2008 6:00 pm Post subject: |
|
|
Unfortunately now I'm running into snmp timeout situations, I've tried increasing the timeout value to 200000 and still getting them  |
|
| Back to top |
|
 |
khufure Cacti User
Joined: 24 Oct 2007 Posts: 164 Location: San Francisco, CA
|
Posted: Fri Nov 21, 2008 6:17 pm Post subject: |
|
|
| jlintz wrote: | Unfortunately now I'm running into snmp timeout situations, I've tried increasing the timeout value to 200000 and still getting them  |
Ouch. That's a gigantic timeout!
One hack used often in getting slow custom stats to function is to pre-gather the data and dump it into a text file for processing. |
|
| Back to top |
|
 |
|