SNMP collection with Arbitrary Indexes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SNMP collection with Arbitrary Indexes

Aaron Scamehorn-2
Hi Aall,

We’ve got some Raritan PDU devices for which I’m not sure how to setup SNMP data collection.  The MIB has arbitrary indexes (for the outlets on the device).

However, in this case, the label’s for each device are not indexed the same, and the OIDs for for the data in question has constants after the indexed dportion.

Here is an example:

The labels I get; they look like the standard arbitrary index examples:

outletLabel.1.1 = STRING: 1
outletLabel.1.2 = STRING: 2
outletLabel.1.3 = STRING: 3
.1.3.6.1.4.1.13742.6.3.5.3.1.2.1.1 = STRING: 1
.1.3.6.1.4.1.13742.6.3.5.3.1.2.1.2 = STRING: 2
.1.3.6.1.4.1.13742.6.3.5.3.1.2.1.3 = STRING: 3

Each OID that I want to collect (rmsCurrent, rmsVoltage, activPower, etc) are below:

PDU2-MIB::measurementsOutletSensorValue.1.1.rmsCurrent = Gauge32: 0 (amp)
PDU2-MIB::measurementsOutletSensorValue.1.2.rmsCurrent = Gauge32: 0 (amp)
PDU2-MIB::measurementsOutletSensorValue.1.3.rmsCurrent = Gauge32: 0 (amp)
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.1 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.2.1 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.3.1 = Gauge32: 0

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)
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.4 = Gauge32: 206
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.2.4 = Gauge32: 206
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.3.4 = Gauge32: 206

PDU2-MIB::measurementsOutletSensorValue.1.1.activePower = Gauge32: 0 (watt)
PDU2-MIB::measurementsOutletSensorValue.1.2.activePower = Gauge32: 0 (watt)
PDU2-MIB::measurementsOutletSensorValue.1.3.activePower = Gauge32: 0 (watt)
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.5 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.2.5 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.3.5 = Gauge32: 0

PDU2-MIB::measurementsOutletSensorValue.1.1.apparentPower = Gauge32: 0 (voltamp)
PDU2-MIB::measurementsOutletSensorValue.1.2.apparentPower = Gauge32: 0 (voltamp)
PDU2-MIB::measurementsOutletSensorValue.1.3.apparentPower = Gauge32: 0 (voltamp)
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.6 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.2.6 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.3.6 = Gauge32: 0

PDU2-MIB::measurementsOutletSensorValue.1.1.activeEnergy = Gauge32: 0 (wattHour)
PDU2-MIB::measurementsOutletSensorValue.1.2.activeEnergy = Gauge32: 0 (wattHour)
PDU2-MIB::measurementsOutletSensorValue.1.3.activeEnergy = Gauge32: 0 (wattHour)
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.7 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.2.7 = Gauge32: 0
.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.3.7 = Gauge32: 0


How would I go about collecting this data?

Attached is the MIB.

Thanks,
Aaron


------------------------------------------------------------------------------
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

pdu2_mib.mib (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SNMP collection with Arbitrary Indexes

Jeff Gehlbach-2
Hi Aaron,

> How would I go about collecting this data?
>
> Attached is the MIB.

This use case is like an onion: it has layers and it's likely to make
one cry. I started out thinking it a great example to show off a new
facility that Alejandro added late last year, but it's less
straightforward than I first thought. I'm essentially putting on
blinders here and focusing on getting the outletLabel to appear on the
same level with the measurement values.

Thanks for including the MIB; the below would have been impossible
without it. Here's my take.

The table containing the outletLabel object is doubly-indexed:

outletConfigurationEntry     OBJECT-TYPE
...
                INDEX         { pduId, outletId }

The table with the measurements is triply-indexed:

outletSensorMeasurementsEntry     OBJECT-TYPE
...
                INDEX         { pduId, outletId, sensorType  }

The first two components match those of the table containing the labels,
but the third is actually an enumerated integer type which denotes the
type of sensor described by the row at hand. This is what we in the
brotherhood call "a pain in the butt". It would be far easier to deal
with if outletId were the final component of both indexes.

If you have multiple different sensor types, you'll need to do extra
work to extract the "sensorType" value from the instance identifier, and
configure a persistence-selector to save only the rows for the sensor
types you care about. For the purposes of this reply, I'm assuming you
have only rmsCurrent sensors.

You'll need to make two resource-types and two groups: one for the
outletConfigurationTable and another for the outletSensorMeasurementsTable.

The former type and group will be totally straightforward.

In the latter group you'll use a new tag, <property>, to "teleport" the
outletLabel string attribute from the first group. It's pretty abstract;
this issue describes its design and operation:

https://issues.opennms.org/browse/NMS-8484

I would expect your setup to look something like:

  <resourceType name="outletConfigurationEntry" label="Raritan PDU
Outlet Configuration" resourceLabel="${outletLabel}">...</resourceType>

  <resourceType name="outletSensorMeasurementsEntry" label="Raritan PDU
Outlet Sensor Measurement" resourceLabel="${outletLabel}">...</resourceType>

  <group name="outletConfigurationTable" ifType="all">
    <mibObj oid=".1.3.6.1.4.1.13742.6.3.5.3.1.2.1"
instance="outletConfigurationEntry" alias="outletLabel" type="string" />
  </group>

  <group name="outletSensorMeasurementsTable" ifType="all">
    <mibObj oid=".1.3.6.1.4.1.13742.6.5.4.3.1.4.1"
instance="outletSensorMeasurementsEntry" alias="outletSensorValue"
type="gauge" />
    <property instance="outletSensorMeasurementsEntry"
source-type="outletConfigurationEntry" source-alias="outletLabel"
index-pattern="^(.+)\.\d+$" />
  </group>

The final layer is the first index component, "pduId". I pegged its
value to "1" in all the above configs. If you need to handle rows where
that identifier has a different value, you'll probably do best to
configure different versions of the "outletSensorMeasurementsEntry"
resource-type and the "outletSensorMeasurementsTable" group.

I hope this helps more than it confuses!

-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
Reply | Threaded
Open this post in threaded view
|

Re: SNMP collection with Arbitrary Indexes

Aaron Scamehorn-2
Thanks, Jeff.  Pain in the butt is an understatement...

Attached is the XML file that I’ve come up with following your advice.

I’m getting closer, but not quite there…..

You are correct that there are multiple different sensor types, and with current config, I am getting them all.  Ultimately, I’ll want to reduce this, but I’m not worried about that yet.


On the web page, I'm see this:




And an ls of the outletSensorMeasurementsEntry looks like this:

$ ls outletSensorMeasurementsEntry/
10.1   1.23   14.7   17.1   19.5   21.8   24.23  26.6   29.1   31.4   33.8   36.14  38.5   41.1   43.4   45.7   48.1   50.6   52.8   5.8   8.5
10.14  12.4   14.8   17.14  19.6   22.1   24.4   26.7   29.14  31.5   3.4    36.23  38.6   41.14  43.5   45.8   48.14  50.7   53.1   6.1   8.6
10.23  12.5   1.5    17.23  19.7   22.14  24.5   26.8   29.23  31.6   34.1   36.4   38.7   41.23  43.6   4.6    48.23  50.8   53.14  6.14  8.7
10.4   12.6   15.1   17.4   19.8   22.23  24.6   2.7    29.4   31.7   34.14  36.5   38.8   4.14   43.7   46.1   48.4   5.1    53.23  6.23  8.8
10.5   12.7   15.14  17.5   20.1   2.23   24.7   27.1   29.5   31.8   34.23  36.6   39.1   41.4   43.8   46.14  48.5   51.1   53.4   6.4   9.1
10.6   12.8   15.23  17.6   20.14  22.4   24.8   27.14  29.6   32.1   34.4   36.7   39.14  41.5   4.4    46.23  48.6   51.14  53.5   6.5   9.14
10.7   13.1   15.4   17.7   20.23  22.5   2.5    27.23  29.7   32.14  34.5   36.8   39.23  41.6   44.1   46.4   48.7   51.23  53.6   6.6   9.23
10.8   13.14  15.5   17.8   20.4   22.6   25.1   27.4   29.8   32.23  34.6   3.7    39.4   41.7   44.14  46.5   48.8   5.14   53.7   6.7   9.4
1.1    13.23  15.6   1.8    20.5   22.7   25.14  27.5   30.1   3.23   34.7   37.1   39.5   41.8   44.23  46.6   49.1   51.4   53.8   6.8   9.5
11.1   13.4   15.7   18.1   20.6   22.8   25.23  27.6   30.14  32.4   34.8   37.14  39.6   42.1   44.4   46.7   49.14  51.5   5.4    7.1   9.6
11.14  13.5   15.8   18.14  20.7   23.1   25.4   27.7   30.23  32.5   3.5    37.23  39.7   42.14  44.5   46.8   49.23  51.6   54.1   7.14  9.7
11.23  13.6   1.6    18.23  20.8   23.14  25.5   27.8   30.4   32.6   35.1   37.4   39.8   42.23  44.6   4.7    49.4   51.7   54.14  7.23  9.8
1.14   13.7   16.1   18.4   2.1    23.23  25.6   2.8    30.5   32.7   35.14  37.5   40.1   4.23   44.7   47.1   49.5   51.8   54.23  7.4
11.4   13.8   16.14  18.5   21.1   23.4   25.7   28.1   30.6   32.8   35.23  37.6   40.14  42.4   44.8   47.14  49.6   52.1   54.4   7.5
11.5   1.4    16.23  18.6   21.14  23.5   25.8   28.14  30.7   33.1   35.4   37.7   40.23  42.5   4.5    47.23  49.7   52.14  54.5   7.6
11.6   14.1   16.4   18.7   21.23  23.6   2.6    28.23  30.8   33.14  35.5   37.8   40.4   42.6   45.1   47.4   49.8   52.23  54.6   7.7
11.7   14.14  16.5   18.8   2.14   23.7   26.1   28.4   3.1    33.23  35.6   3.8    40.5   42.7   45.14  47.5   50.1   5.23   54.7   7.8
11.8   14.23  16.6   19.1   21.4   23.8   26.14  28.5   31.1   33.4   35.7   38.1   40.6   42.8   45.23  47.6   50.14  52.4   54.8   8.1
12.1   14.4   16.7   19.14  21.5   2.4    26.23  28.6   31.14  33.5   35.8   38.14  40.7   43.1   45.4   47.7   50.23  52.5   5.5    8.14
12.14  14.5   16.8   19.23  21.6   24.1   26.4   28.7   31.23  33.6   3.6    38.23  40.8   43.14  45.5   47.8   50.4   52.6   5.6    8.23
12.23  14.6   1.7    19.4   21.7   24.14  26.5   28.8   3.14   33.7   36.1   38.4   4.1    43.23  45.6   4.8    50.5   52.7   5.7    8.4


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.


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

1.23:
outletSensorValue.jrb  outletSensorValue.meta

1.4:
outletSensorValue.jrb  outletSensorValue.meta

1.5:
outletSensorValue.jrb  outletSensorValue.meta

1.6:
outletSensorValue.jrb  outletSensorValue.meta

1.7:
outletSensorValue.jrb  outletSensorValue.meta

1.8:
outletSensorValue.jrb  outletSensorValue.meta


And the contents of a meta file:

$ cat 1.8/outletSensorValue.meta
#Thu Jul 27 09:23:33 CDT 2017
GROUP=outletSensorMeasurementsTable
SNMP_.1.3.6.1.4.1.13742.6.5.4.3.1.4.1.1.8=outletSensorValue

The above OID is actually:
PDU2-MIB:measurementsOutletSensorValue.1.1.activeEnergy = Gauge32: 0

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


Thanks,
Aaron






> On Jul 27, 2017, at 5:23 PM, Jeff Gehlbach <[hidden email]> wrote:
>
> Hi Aaron,
>
>> How would I go about collecting this data?
>>
>> Attached is the MIB.
>
> This use case is like an onion: it has layers and it's likely to make
> one cry. I started out thinking it a great example to show off a new
> facility that Alejandro added late last year, but it's less
> straightforward than I first thought. I'm essentially putting on
> blinders here and focusing on getting the outletLabel to appear on the
> same level with the measurement values.
>
> Thanks for including the MIB; the below would have been impossible
> without it. Here's my take.
>
> The table containing the outletLabel object is doubly-indexed:
>
> outletConfigurationEntry     OBJECT-TYPE
> ...
>                INDEX         { pduId, outletId }
>
> The table with the measurements is triply-indexed:
>
> outletSensorMeasurementsEntry     OBJECT-TYPE
> ...
>                INDEX         { pduId, outletId, sensorType  }
>
> The first two components match those of the table containing the labels,
> but the third is actually an enumerated integer type which denotes the
> type of sensor described by the row at hand. This is what we in the
> brotherhood call "a pain in the butt". It would be far easier to deal
> with if outletId were the final component of both indexes.
>
> If you have multiple different sensor types, you'll need to do extra
> work to extract the "sensorType" value from the instance identifier, and
> configure a persistence-selector to save only the rows for the sensor
> types you care about. For the purposes of this reply, I'm assuming you
> have only rmsCurrent sensors.
>
> You'll need to make two resource-types and two groups: one for the
> outletConfigurationTable and another for the outletSensorMeasurementsTable.
>
> The former type and group will be totally straightforward.
>
> In the latter group you'll use a new tag, <property>, to "teleport" the
> outletLabel string attribute from the first group. It's pretty abstract;
> this issue describes its design and operation:
>
> https://issues.opennms.org/browse/NMS-8484
>
> I would expect your setup to look something like:
>
>  <resourceType name="outletConfigurationEntry" label="Raritan PDU
> Outlet Configuration" resourceLabel="${outletLabel}">...</resourceType>
>
>  <resourceType name="outletSensorMeasurementsEntry" label="Raritan PDU
> Outlet Sensor Measurement" resourceLabel="${outletLabel}">...</resourceType>
>
>  <group name="outletConfigurationTable" ifType="all">
>    <mibObj oid=".1.3.6.1.4.1.13742.6.3.5.3.1.2.1"
> instance="outletConfigurationEntry" alias="outletLabel" type="string" />
>  </group>
>
>  <group name="outletSensorMeasurementsTable" ifType="all">
>    <mibObj oid=".1.3.6.1.4.1.13742.6.5.4.3.1.4.1"
> instance="outletSensorMeasurementsEntry" alias="outletSensorValue"
> type="gauge" />
>    <property instance="outletSensorMeasurementsEntry"
> source-type="outletConfigurationEntry" source-alias="outletLabel"
> index-pattern="^(.+)\.\d+$" />
>  </group>
>
> The final layer is the first index component, "pduId". I pegged its
> value to "1" in all the above configs. If you need to handle rows where
> that identifier has a different value, you'll probably do best to
> configure different versions of the "outletSensorMeasurementsEntry"
> resource-type and the "outletSensorMeasurementsTable" group.
>
> I hope this helps more than it confuses!
>
> -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


------------------------------------------------------------------------------
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

Raritan2.xml (4K) Download Attachment