我很努力地将我的APC RackPDU的加载graphics加载到OpenNMS中。 我已经在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>
并且使用snmpget
我能够检索有问题的值:
# 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
我还在snmp-graph.properties
定义了一个报告来处理收集的数据,但我甚至没有看到它被收集。 主机的rrd目录(在我的情况下是rrd/snmp/170
)只包含通用的icmp.*.jrb
和tcp*.jrb
数据文件,没有预期的rPDUCurB1 / rPDUCurB2文件的符号。
我已经尝试清除rrd/snmp/170
并强制在节点上进行能力扫描,但只是出现了相同的文件。 RackPDU
(组定义名称)或rPDUCur
(值别名)的快速日志grep什么都不产生。
我怀疑能力没有被正确检测,但我不知道如何进一步debugging它。
编辑:我增加了collectd的日志级别为“debugging”和一些可疑的线路已被logging有关的节点:
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
这让我想知道为什么 OIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2
,但是我尝试将组的定义更改为<group name = "APC-RackPDU" ifType="-2">
(根本不工作,在OpenNMS启动时抛出一个validation错误)和<group name = "APC-RackPDU" ifType="all">
(工作并生成了OIDs from group 'APC-RackPDU:all' are included for ifType: -2
的OIDs from group 'APC-RackPDU:all' are included for ifType: -2
在日志中的OIDs from group 'APC-RackPDU:all' are included for ifType: -2
,但没有进一步的帮助)。
在定义我的新组时,我使用APC UPS定义作为模板,而在组装用于snmpget
testing的OID时不注意“实例”属性。 将定义更改为
<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
解决了这个问题。 当看到Jeff Gehlbach回答的OpenNMS邮件列表中的一个旧post的时候,我有了正确的想法 – 信用卡到期了。
最好的方法是通过OpenNMS IRC频道来运行。 我相信他们已经看到了这个设备,因为这是相当常见的。