The newer OIDs come from a newer version of the MIB.

Incidentally, 1300 / 100 is 13. If it was displaying 0.13, then there is some maths failure within the polling code (or discovery is storing the wrong settings in the database).

The older one only has snAgentCpuUtilValue :

snAgentCpuUtilValue OBJECT-TYPE
        SYNTAX  Gauge
        ACCESS  read-only
        STATUS  mandatory
        DESCRIPTION
                "The statistical CPU utilization in units of one-hundredth of a percent."
        ::= { snAgentCpuUtilEntry 4 }

adam.

On 2012-04-30 13:48, Matthias Cramer wrote: 
Hi All

Sorry, if I did a "quick fix" but when I use it like this, the values correspond with what I see when i do a
"sh cpu-utilization" or "sh cpu-utilization lp".

when I do a get in the main CPU it looks like that

orpheus:/opt/observium# snmpget -v2c -c community zelja.zh.as8758.net .1.3.6.1.4.1.1991.1.1.2.11.1.1.6.1.1.300
SNMPv2-SMI::enterprises.1991.1.1.2.11.1.1.6.1.1.300 = Gauge32: 1300

And that is relay 13% and not 0.13% as it showed for me before...

Something is weird here. So I looked at the source and the Database. Observium seams to use ".1.3.6.1.4.1.1991.1.1.2.11.1.1.4.1.1.300"
and this returns whole precents. The SNMP Walk to snAgentCpuUtilEntry does not return any of the snAgentCpuUtil100thPercent oid's.
I run a very recent version of Ironware, so either there is an other tree to get the "no depreciated" values or the MIB lies.

Anyways, my patch is wrong. And the MIB is probably too, at least snAgentCpuUtilValue does not return "one-hundredth of a percent".

In the meantime I also checked this against a RX8 and RX16 with the same result.

In which MIB have you found the snAgentCpuUtil100thPercent? It's not int any MIB provided with observium nor in any I have downloaded from Brocade.

Also in my MIB File STATUS is mandatory and not deprecated!

Regards

  Matthias


On 30/04/12 13:20, Adam Armstrong wrote:

Both of the OIDs we use are in hundredths of a percent. There is the non-hundredths OID, but we don't use it.

snAgentCpuUtilValue OBJECT-TYPE
	SYNTAX		Gauge32
	MAX-ACCESS	read-only
	STATUS		deprecated
	DESCRIPTION
		"The statistical CPU utilization in units of one-hundredth
		 of a percent. This value is deprecated. Users are recommended
		 to use snAgentCpuUtilPercent or snAgentCpuUtil100thPercent
		 instead."
	::= { snAgentCpuUtilEntry 4 }

snAgentCpuUtilPercent OBJECT-TYPE
	SYNTAX		Gauge32
	MAX-ACCESS	read-only
	STATUS		current
	DESCRIPTION
		"The statistical CPU utilization in units of a percent."
	::= { snAgentCpuUtilEntry 5 }

snAgentCpuUtil100thPercent OBJECT-TYPE
	SYNTAX		Gauge32
	MAX-ACCESS	read-only
	STATUS		current
	DESCRIPTION
		"The statistical CPU utilization in units of one-hundredth
		 of a percent."
	::= { snAgentCpuUtilEntry 6 }


Please be more careful when "fixing" things, and find out what the data actually should be!

adam.

On 2012-04-30 12:11, Tom Laermans wrote:

Matthias,

That sounds odd - the OID describes it as 100th of a Percent, and the patch was tested against Brocades before commit.

Maybe it's a bug?

Tom

On 30/04/2012 12:54, Matthias Cramer wrote:

Hi

The scale of the discovered CPU's on Ironware based geer is off by factor 100.
This patch will fix that. Tested on Brocade XMR4000

Regards

  Matthias


Index: includes/discovery/processors/ironware.inc.php
===================================================================
--- includes/discovery/processors/ironware.inc.php	(revision 3098)
+++ includes/discovery/processors/ironware.inc.php	(working copy)
@@ -15,11 +15,11 @@
       {
         $usage_oid = ".1.3.6.1.4.1.1991.1.1.2.11.1.1.6." . $index;
         $usage = $entry['snAgentCpuUtil100thPercent'];
-          $precision = 100;
+          $precision = 1;
       } elseif ($entry['snAgentCpuUtilValue']) {
         $usage_oid = ".1.3.6.1.4.1.1991.1.1.2.11.1.1.4." . $index;
         $usage = $entry['snAgentCpuUtilValue'];
-        $precision = 100;
+        $precision = 1;
       }

       list($slot, $instance, $interval) = explode(".", $index);



_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium



_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium



_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium





_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium