Re: SNMP collection with Arbitrary Indexes

On 07/28/2017 09:21 AM, Aaron Scamehorn wrote:

> Attached is the XML file that I’ve come up with following your advice.
> 
> I’m getting closer, but not quite there…..

How's it coming?

I finally found a block of time to look back at this. Your config looks
okay at a glance. I don't have a device of this type lying around to
test against, though.

> I guess I expected to see 54 sub-dirs (one for each outlet) with 8 JRB’s
> in each.  And I’m assuming that’s why the ${outletLabel} isn’t quite
> working.

That would be the ideal, but as it exists today, the resource model
lacks a  concept of nested resource types. I'm not aware of any work
underway to change it in the near future, so we're left with tricks like
the <property> tag to copy over the value.

> I’m wondering too, for graphing purposes, how to specify a JRB to graph
> (column)…  As it is currently, all of the JRB’s have the same name:
> 
> This is the contents of the outletSensorMeasurementEntry/1.* dirs:
> $ ls 1.*
> 1.1:
> outletSensorValue.jrb  outletSensorValue.meta
> 
> 1.14:
> outletSensorValue.jrb  outletSensorValue.meta

They're named alike because they're instances of the same attribute
(where "attribute" is a generic term, implemented in this case as a
<mibObj> or <property> tag inside a <group>). Just as "sysName" is
called the same thing on every node, "outletSensorValue" is called that
on every resource for which it's present.

If you want to refer to a specific instance of an attribute, you need to
use a resource ID. For example, if the node ID is 12345 and you want the
1.14 instance of an attribute, you would ask for:

node[12345].outletSensorMeasurementsEntry[1.14]

You can see this syntax in action by getting resource graphs for any
resource and looking at the URL in your browser's address bar; a value
similar to the above will be the value of the "resourceId" URL parameter.


> I guess I was hoping that I’d have a JRB name with the corresponding
> measurement (from the MIB:  rmsCurrent, rmsVoltage, ativePower,
> apparentPower).

That's a totally reasonable expectation, and its unfulfilled status is
the nut we're trying to crack here. You're only having the problem
because this MIB flips the ordering of indices on its head versus the
usual case. Looking back to your original post, you provided this sample
of walk output:


PDU2-MIB::measurementsOutletSensorValue.1.1.rmsVoltage = Gauge32: 206 (volt)
PDU2-MIB::measurementsOutletSensorValue.1.2.rmsVoltage = Gauge32: 206 (volt)
PDU2-MIB::measurementsOutletSensorValue.1.3.rmsVoltage = Gauge32: 206 (volt)

Compare that to a more typical arrangement where the instance identifier
part (1.1, 1.2, 1.3) is at the end, which would look something like this
(object names are hypothetical):

PDU2-MIB::measurementsOutletSensorRmsVoltage.1.1 = Gauge32: 206 (volt)
PDU2-MIB::measurementsOutletSensorRmsVoltage.1.2 = Gauge32: 206 (volt)
PDU2-MIB::measurementsOutletSensorRmsVoltage.1.3 = Gauge32: 206 (volt)

The latter situation is what a sensible table's data looks like, and
it's what the SNMP collector was designed to understand effortlessly.
Because the designer of this MIB was being clever (or lazy, or
impatient, who knows) the instance ID falls in the middle. It's not
wrong per se, but it's unusual enough to cause problems. I'm not sure of
the best way to compensate for it.

Make sense?

-jeff

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss