Я изо всех сил пытаюсь получить графики загрузки моего APC RackPDU в 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 и принудительное сканирование возможностей узла, но оно выходит с теми же файлами. Быстрый журнал grep для RackPDU (имя определения группы) или rPDUCur (имя псевдонима значения) ничего не дало.
Я подозреваю, что возможности не определяются правильно, но я не знаю, как отлаживать их дальше.
Изменить: я увеличил уровень журнала collectd до «DEBUG», и были зарегистрированы некоторые подозрительные строки о рассматриваемом узле:
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) и <group name = "APC-RackPDU" ifType="all"> (который работал и произвел OIDs from group 'APC-RackPDU:all' are included for ifType: -2 в логах, но дальше дела не помогли).
Я прострелил себе ногу, используя определения APC UPS в качестве шаблона при определении моей новой группы и не обращая внимания на атрибут «instance» при сборке OID для тестирования с snmpget. Изменение определения на
<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
исправил проблему. Я правильно понял, глядя на старую размещение в списке рассылки OpenNMS, на который ответил Джефф Гелбах - кредит там, где он причитается.
Лучшим подходом было бы запустить это через IRC-канал OpenNMS. Я уверен, что они видели данное устройство, поскольку оно довольно распространено.