1

I am struggling to get load graphs of my APC RackPDU into OpenNMS. I've defined the appropriate values in datacollection-config.xml:

<groups>
  <group name = "APC-RackPDU" ifType="ignore">
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.2" instance="0" alias="rPDUCurB1" type="Gauge32" />
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.3" instance="0" alias="rPDUCurB2" type="Gauge32" />
  </group>
</groups
<systems>
  <systemDef name="APC UPS">
    <sysoidMask>.1.3.6.1.4.1.318.</sysoidMask>
    <collect>
      <includeGroup>APC</includeGroup>
      <includeGroup>APC-RackPDU</includeGroup>
      <includeGroup>mib2-ups-rfc1628</includeGroup>
    </collect>
  </systemDef>
</systems>

And using snmpget I am able to retreive the values in question:

# snmpget -v2c -c public 192.168.127.133 .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.3
SNMPv2-SMI::enterprises.318.1.1.12.2.3.1.1.2.3 = Gauge32: 38

I've also defined a report in snmp-graph.properties to work on the collected data, but I do not even see it being collected. The host's rrd directory (rrd/snmp/170 in my case) only containts generic icmp.*.jrb and tcp*.jrb data files without a sign of the expected rPDUCurB1 / rPDUCurB2 files.

I've tried cleaning the rrd/snmp/170 and forcing a capability scan on the node, but it just comes out with the same files. A quick log grep for RackPDU (the group definition name) or rPDUCur (the value alias name) yielded nothing.

I would suspect that the capabilities are not detected correctly, but I have no idea how to debug it any further.

Edit: I increased the log level of collectd to "DEBUG" and some suspicious lines have been logged about the node in question:

2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: getMibObjectList: collection: default sysoid: .1.3.6.1.4.1.318.1.3.4.5 address: 192.168.127.133 ifType: -2
[...]
DefaultDataCollectionConfigDao: getMibObjectList: includes sysoid .1.3.6.1.4.1.318.1.3.4.5 for system <name>: APC UPS
2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: getMibObjectList: MATCH!! adding system 'APC UPS'
2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] [...]
DefaultDataCollectionConfigDao: processGroupName:  processing group: APC groupIfType: ignore ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName: OIDs from group 'APC:ignore' are excluded for ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName:  processing group: APC-RackPDU groupIfType: ignore ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName: OIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2

It made me wonder why exactly OIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2, but I tried to change the definition of the group to <group name = "APC-RackPDU" ifType="-2"> (which did not work at all and threw a validation error upon OpenNMS startup) and <group name = "APC-RackPDU" ifType="all"> (which worked and produced an OIDs from group 'APC-RackPDU:all' are included for ifType: -2 in the logs, but did not further help matters).

Improve this question

2 Answers 2

Reset to default
1

I shot in my own foot by using the APC UPS definitions as my template when defining my new group and not paying attention to the "instance" attribute when assembling the OIDs for testing with snmpget. Changing the definition to

<groups>
  <group name = "APC-RackPDU" ifType="ignore">
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2" instance="2" alias="rPDUCurB1" type="Gauge32" />
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2" instance="3" alias="rPDUCurB2" type="Gauge32" />
  </group>
</groups

fixed the problem. I got the right idea when looking at an old posting to the OpenNMS mailing list answered by Jeff Gehlbach - credit where it is due.

Improve this answer
0

The best approach would be to run this by the OpenNMS IRC channel. I'm sure they've seen the device in question since it is fairly common.

Improve this answer
1
  • It's not so much about the device itself. I am sure I've got the OIDs right, bur I think I forgot something essential within the definition and I am not seeing it. Hoped somebody could break my mental block.
    – the-wabbit
    Apr 17, 2012 at 10:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .